In the Liquibase Tutorial using Oracle it shows the contents of an install.xml file, that includes package specifications (pks) and package bodies (pkb), the order of installation is very logical, (tables, then sequences, constraints, package specifications, views, package bodies, and triggers)
But there are more object types to consider in Oracle: functions, procedures and database links are the ones that come to my mind right now.
Functions and procedures aren’t as easy to deal with as packages, there is no spec, so there might be invalid objects after compilation because of dependencies if objects are not compiled in the correct order, what should I do then? I guess you’ll say that I’ve got to explicitly indicate order of compilation in the changeset, that wouldn’t be so easy on a big project with many objects, not as easy as the changeset defined above.
The worst scenario:
What if there is a function A which calls function B, and B calls A too (I know that is not very common, but it can happen, specially in big projects), what order should compilation take? What if any order in changeset takes me to a compilation with errors? Would that be considered an unsuccessful migration?
If there is no way to save me from a compilation with errors, what should I do then? should I try to compile all invalid objects over and over again until there are no invalid objects? Can Liquibase help me with that?
Liquibase Tutorial using Oracle shows a “one-database one-user-schema” scenario (there are really 3 user schemas in this tutorial, but there are 3 releases of the same project), and it doesn’t show anything about procedures and functions (see first post)
This scenario is more common when you sell an application, but when you work on an organization that develops it’s own software, there are many in-house applications, therefore many databases, many user schemas on each database, objects from user1 that call objects of user2, user1 may be in the same database, or not (database links).
What approach should I take then? Does Liquibase Tutorial using Oracle work for me still? Is there an example of this “many-database many-user-schemas” scenario? If there is no example of this, I recommend making a new tutorial that takes care of this scenario (many databases with dblinks, calls from one user schema to another, procedures and functions outside of packages).
In Liquibase Tutorial using Oracle, you see there is a table created called DATABASECHANGELOG inside of one user schema, is it maybe that I can log all user schemas on that table?
Sorry you haven’t gotten a response so far. I would say that the oracle tutorial is an example liquibase usage, but is in no way the only, or often times the best way to organize your changesets. In the end, liquibase sees a set of databasechangelog files as a single sequential list of changes to apply, and it starts at the beginning and applies each one in turn as long as it has not yet been ran (according to the database’s databasechangelog table).
How you best apply liquibase to your particular use can vary greatly, and it can get more complex as your database becomes more complex.
In your case, it may make more sense to break up included changelogs by functional area or by release. You can create the “root” objects first, then create the objects that depend on them later in the changelog without worrying about the type of object it is.
Think of a changelog as a database creation script. What order would you create objects in, and what what logical break down would make them the easiest for you to deal with?
Note: if you think it would be helpful to have a consultant or trainer who can better understand how you are looking to use liquibase and how it can be best applied to your particular database, we do have independent 3rd party groups we can set you up with at liquibase.com.
