Hello; I’m circling around LiquiBase, looking at it for a very large project with a lot of visibility. Consequently I’m nervous and want to make sure that I fully understand the general problem area before I start hacking.
I had a question related to change logs over time.
In the training videos and examples that I’ve watched so far (I’m about 2/3 of the way through the long one), there isn’t much discussion of what happens if a change log is “shortened”. By that I mean obvious mistake entries being consolidated into correct entries, or six individual column renamings combined into one change set, and so on.
Is it expected that a change log will only ever be appended to, or can the change log itself be refactored?
If I have a change log entry that creates one table, and then another one that creates another table, and then seventeen others that affect the data in those tables, what happens if I consolidate those two entries into one after the fact, check it into version control, and run liquibase update? Semantically it’s the same thing: I have created two tables and filled them with data, but I don’t see how LiquiBase could know that.
Or: if I have three entries in my changelog that are designed to back out some kind of boneheaded column misspelling mistake, I’d kind of like to make it so that I don’t have to air that dirty laundry in front of my customers. It would be nice to be able to smush the column renaming operation together with the spelling correction after the fact. Does LiquiBase do this sort of thing already?
Are there general rules for changelog maintenance on a large project?
Thanks very much for any pointers in this regard, and thanks for what looks like a really interesting project.