From: Fred T. <fr...@us...> - 2016-09-07 22:00:25
|
Non-transactional DDL has always been the case. If your DDL statements do not contain syntax errors or references to non-existent database objects, then they won't fail the first time they are executed. The IF NOT EXISTS clause can be used with all database objects. You can query the INFORMATION_SCHEMA views to check if a table or other object exists, before creating database objects. You can always drop the whole schema if you want to recreate it. Fred On Wed, Sep 7, 2016, at 22:17, lis...@io... wrote: > Hello! > > On 2016-09-07T22:08:06 +0100 > Fred Toussi <fr...@us...> wrote: > > > > A DDL statement is not transactional. A commit is executed implicitly > > both before and after the statement execution. > > > > If you want to avoid the exception when the statement is executed the > > second time, use: > > > > CREATE CACHED TABLE IF NOT EXISTS broken ... > > > > Statements such as INSERT or DELETE are transactional and will be rolled > > back when you call rollback() on the connection. > > That's bizarre. Has this always been the case? > > I remember a few years back trying to decide between HSQLDB and H2, and > picking HSQLDB because DDL statements appeared to be transactional. > > Without transactional DDL, how do I guarantee that my database is set > up correctly and atomically? With implicit commits, any failure means > that I end up with a half configured database that has to then be > destroyed and created from scratch. > > M > ------------------------------------------------------------------------------ > _______________________________________________ > Hsqldb-user mailing list > Hsq...@li... > https://lists.sourceforge.net/lists/listinfo/hsqldb-user > Email had 1 attachment: > + Attachment1.2 > 1k (application/pgp-signature) |