Closed srcshelton closed 8 years ago
OLDSCHEMA
is a debug option, and should not be used.
There are a few bugs outstanding in the myway.pl migration code (a few more now fixed and being tested in integration than currently in master!) but it's now much improved.
Known failures are:
--init
'd and metadata tables created before the current run but no further migrations have been applied (we see that schema_versions
is empty and so assume that the database is a clean deployment with current schema, when the schema is actually old);titan
, for reasons currently unclear.I'm tempted to remove all of the inference currently used and simply perform more time-consuming but direct checks of the current state of the schema, and migrate as appropriate...
(... although the current implementation is intended to support many migrations over time as necessary and the current code attempts to handle any number of generic upgrades - this is good. What's needed is a way to tell the difference between a fresh new installation and a fresh legacy installation without specific knowledge of the exact changes entailed in the migration process)
Originally, we did CREATE TABLE IF NOT EXISTS ...
followed immediately by INSERT IGNORE ...
to load the current schema version. This broke when the table actually did exist, and was then updated erroneously to indicate that it was of the current standard. We're now only setting the metadata as current once we've checked the schemata state, but hit the edge-case above on otherwise empty databases.
Should be fixed by 94083a7, but leaving open for now in case there are further edge-cases are found...
Final call for any update on this issue, otherwise closing shortly...
No failures encountered, closing.
When running against already initialised databases (where
myway_version_history
.init_string
has 'INIT
' value), the script is not able to succesfully migrate the database to the new schema format.Interim fix is to run with
OLDSCHEMA=1
.