offline mode seems non-deterministic
Description
Environment
Windows 7 Professional
Java 1.7.0.60-b19
Activity
Nathan Voxland June 23, 2015 at 8:54 PM
I've tried various precondition setups with the 3.4.0 code and it seems to consistently fail with the exception as expected. I've made some changes to the 3.4 codebase previously which may have fixed the inconsistencies.
If you are still seeing problems once 3.4 is out, attach the changelogs you are using and reopen the issue
Rafael Chaves January 13, 2015 at 3:05 PM
Nathan, do you have enough information/insight to tackle this?
Rafael Chaves January 7, 2015 at 7:15 PM
In my test above? Always updateSQL.
The preconditions are always within changesets. We have the following structure in the root changelog:
an included initialization changelog (contains a single change set that wraps a database creation SQL script, and only runs if context=initialization - it has a precondition that ensures the database looks empty, with onFail="HALT" and onSqlOutput="TEST")
a "migration check" changeset (a changeset with runAlways="true", but onFail="HALT" and onSqlOutput="IGNORE") whose only purpose is to stop the process if the database seems to be empty (for instance, the user forgot to speficy changeset=initialize)
one or more included update changelogs (one per release), which make additional changes to the database schema/data and have their own preconditions (does the schema/data I am supposed to create already exist? If so, mark me as RAN, i.e. they have onSqlOutput="TEST", and onFail="MARK_RAN") and
Nathan Voxland January 7, 2015 at 6:56 PM
A couple questions:
1. Are you always running updateSQL? Or sometimes update and sometimes updateSQL?
2. Are all the preconditions within changeSets? Some changelog level ones? A mix?
Trying the support for offline SQL generation (implemented in and documented here).
I have a change log with change sets that have preconditions (that access the DB) and are set as onSqlOutput="TEST".
I am seeing quite erratic behavior. Any of the following may happen:
the changelog is processed and the expected SQL is generated (preconditions are not executed)
the changelog is processed with the preconditions deemed as unsatisfied (probably not actually executed)
the changelog processing fails due to the precondition being evaluated (stack trace below)
The bare expectation is that it worked always the same way (note that the offline mode generates a csv file that if not deleted will affect the result of a following execution). In my tests I always delete the file.