This is the bug tracker for Photo Organizer.
FS#210 - Re-base intial SQL data
Attached to Project:
Photo Organizer
Opened by Solomon Peachy (pizza) - Wednesday, 06 June 2007, 17:55 GMT-4
Last edited by Solomon Peachy (pizza) - Wednesday, 28 November 2007, 18:34 GMT-4
Opened by Solomon Peachy (pizza) - Wednesday, 06 June 2007, 17:55 GMT-4
Last edited by Solomon Peachy (pizza) - Wednesday, 28 November 2007, 18:34 GMT-4
|
DetailsFor new installations we start with a PO 2.05 schema+data and then apply each new version in turn. This is quite silly, and makes installations much more complex than necessary.
PO.n PO.n+1 PO.n+2 ... PO.n+m The install needs to be re-worked so that it installs the latest complete schema in its entirety, plus any necessary data. Upgrades would be applied via a similar mechanism. PO.n-2 PO.n-1 PO.n This also lets us cut out a considerable amount of historical cruft; there are many tables that are set up only to be deleted later, and a great deal of migration code that is not necessary on a new install. |
This task depends upon
Closed by Solomon Peachy (pizza)
Wednesday, 28 November 2007, 18:34 GMT-4
Reason for closing: Implemented
Additional comments about closing: we now support upgrades from v2.29, which is the last release by Balint.
I'm not going back further than this.
Wednesday, 28 November 2007, 18:34 GMT-4
Reason for closing: Implemented
Additional comments about closing: we now support upgrades from v2.29, which is the last release by Balint.
I'm not going back further than this.
2.35 is also scheduled to have the new database backend (via PHP:PDO) so the installer should be updated to use this too.
(Another thing worth investigating is using a schema diff tool; perhaps even automated)
pre_function
db_file_1
upgrade_function
db_file_2
post_function
this way all db schema modifications can be performed by schema files instead of scripts.
1) Add a "serial number" to the database, or adapt the current 'version' table to be more flexible.
major.minor.variation
2) Generate a full, current schema+data dump of a fresh install, including the repository layout creation.
3) Generate a sane "upgrade from version (n-1)" function + script.
4) Run the following psuedocode
if (curr_serial_num == null)
load_full_current_schema
else
for (i = curr_serial_num; exists(upgrade_data[i]); i++) {
if (update_fn[i]) update_fn[i];
else if (schema_diff[i]) apply_schema_diff(i);
}
The idea is that each DB file or upgrade function includes a serial number change for each DB commit. This way if an upgrade step fails, we can easily resume from a known point.
5) Figure out a sane mechanism to use on -devel, where incrementing the serial number for each DB change might be stupid....
As time permits, support for upgrading older versions will be added. I'd like to support at least 2.33, but the goal I'm shooting for is to support upgrades as far back as v2.29.
The output is slightly different from what our parser expects, unfortunately, so the installer needs tweaking..
I need to test out real upgrades from 2.33, and 2.34.
Need to re-run it for the -stable demo site.