You do need to have the schema that the databasechangelog table exists in created before running liquibase. We track all our changes in that table, and so we need to access it as part of liquibase start up. For now, you will will need to create the schema in some other way, then use liquibase.
I was hoping that it was possible to specify a sql() which would run before liquibase “really” started.
That way we could set up everything from scratch in an empty, clean database. Very nice for unit testing.
I agree and have thought about it a bit, but it is sort of a chicken and egg problem. When starting liquibase, we don’t know what initial startup we need to do because we can’t check the table in the schema to know what we have already done.
I’ve thought about having a block before the changesets that would describe the schema and other pre-liquibase-execution items, but I tend to think that is too much of a database administration feature. For example, we could create schemas, but what about creating users Would you include the password in the changelog file? Assigning users to the given schema? etc. Also, many of those activities require a database user with more permissions than the user you should be executing your liqubase scripts as.
Yes, it is too much database specific administration.
I now use the Ant target before called liquibase.
drop schema ${db.schema} if exists;
create schema ${db.schema};
But for Oracle where a schema is a user, and you need grants, the statements are very different.
It would just be nice to have these specific statements in a liquibase xml file with the “dbms” switch, and maybe in the context “create new database from scratch”.