ChangeSet.getChanges is read only because the code has not necessarily been tested with dynamic changes to the list of changes in it. There is a ChangeSet.addChanges method to add a change but not anything to remove it currently. The list returned is not modifiyable but the Changes contained in it can be edited.
Changes do not have identifiers because they have not been needed so far. ChangeSets have a unique identifier and are tracked by liquibase, but the change implementations are just anonymously contained in the ChangeSet. If they had a unique identifeir, it would probably just be ChangeSet.id+ChangeSet.author+ChangeSet.filePath+indexOfChange
Preconditions are only at the changeSet level because that is the level liquibase works at and tries to run as a transaction. If you want preconditions per change you will need to have just one change per changeSet (most of the time you want this anyway because DDL statements autocommit which can get liquibase into a bad state if a second change fails).
There are several ways to preview SQL generation. If you have a Change object, calling change.generateStatements(database) will return an array of statements, each of which can be passed to SqlGeneratorFactory.getInstance().generateSql(statement, database)
Nathan
Hello
I have some doubts about liquibase core classes:
- Why does liquibase.changelog.Changeset#getChanges return an unmodifiableList since I'd like to manipulate (directly delete or edit+update a change)?
- Why doesn't liquibase.change.Change implementation has not an identifier, since I am using this classes directly binded in JSF pages?
- When using N changes within a changeset, could I use tag? Is there any alternative or do I need to implement 1-1 change-changeset?
- Is it possible to preview SQL generation by passing Change implementation and Database object somewhere?
SqlGeneratorFactory.generateSql instead of Liquibase.update? Then after when I choose to run all these stuff directly to Database I can call Liquibase.update.
I created https://liquibase.jira.com/browse/CORE-1771 to track the change to ChangeSet.getChanges to make it modifyable.
You asked your new question in a separate thread, right?
I don’t think it’s bad practice to use SqlGeneratorFactory directly. I’ve tried to design the liquibase API with an onion skin architecture with exposed lower level APIs that are called by higher level APIs. The higher level APIs like liquibase.update() handle standard use cases but there is nothing wrong with using the lower level APIs when the higher level ones do not meet your needs.
Nathan
