Sorry, it got pushed into my “longer response required, will take more time” queue.
The idea of the PreconditionContainer is that its job is to be the facade to whatever preconditions are defined. You construct it with just a call to new PreconditionContainer(). Preconditions themselves are created by a call to PreconditionFactory.getInstance().create(name) which creates the correct precondition object for the given name. You can then set attributes on that precondition (attributes vary by the actual precondtion) and then call precondtionContainer.addNestedPrecondition(precondition) passing the newly created precondition.
The addNestedPrecondition() method exists for all the PrecondtionLogic “preconditions” which are basically the and/or/not groupings of normal preconditions.
If you look at XMLChangeLogSAXHandler we have preconditionLogicStack which is a stack to allow arbitrary nesting of logical preconditoins. The bottom of the stack is the precondtion container and as we create precondions based on the XML, if it is a PrecondtionLogic precondition, we add it to the top of the stack, and if it is a normal precondtion, we add it to the top precondition. As we leave the etc. XML tags we pop the top precondition off the stack since we are done with it until at the end the stack is emply.
I’m not sure how much of that stack logic should be moved into the Precondtion liqubase API and what is XML-handling specific and should be left out.
Any suggestions on how it could be improved?