The columnExists precondition takes about 5 seconds to run on our database. We have about 80 tables and 800+ columns.
Its building up the entire DatabaseSnapshot in a liquibase object before using the generic liquibase calls in each precondition.
I added a patch for mysql databases that does a sql call into the information_schema space. This takes milleseconds to run. (see attached).
Alternatively, the generated DatabaseSnapshot object could be cached until a database modification is done in a changeset, but I didn’t see a quick way to do that.
The tableExists, foreignKeyExists, indexExists, viewExists, etc could stand to have a similar improvement.
(I haven’t looked at the 2.0 branch yet to see if this overall problem is solved)
Modification: Attached a similar patch for indexExists.
The overall problem isn’t fixed in 2.0, although I did create an issue (http://liquibase.jira.com/browse/CORE-434) to look into it. I didn’t commit your patch because I don’t want to be putting database specific code into the precondition code. What we need to do is improve the snapshot generation method to allow the passing of a single object to look up. The snapshot generation logic is greatly improved and modularized in trunk, so it probably won’t be backported to 1.9.
Performance of preconditions has not been a high priority so far because my theory has been that they not checked often, but there are certainly cases where that is not true.
Caching of the snapshot object is something I have thought about as well, but like you said, I think it is too difficult to know when it needs to be refreshed. I think improving the performance of the snapshot process is the best approach.
Nathan
