Photo Organizer

  • Status Closed
  • Percent Complete
  • Task Type Feature Request
  • Category Installer
  • Assigned To No-one
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version Devel
  • Due in Version 2.35
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Photo Organizer
Opened by pizza - 2007-06-06
Last edited by pizza - 2007-11-28

FS#210 - Re-base intial SQL data

For 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.


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.


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.

Closed by  pizza
2007-11-28 23:34
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.
pizza commented on 2007-06-06 22:04

Initial plan would be to target 2.35 for this; an upgrade path from 2.34 would be provided, but pre-2.34 would require upgrading to 2.34 first, then 2.35+. The installer could therefore lose all pre-2.34 migration code.

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)

pizza commented on 2007-10-19 16:09

also worth doing is updating the installer to use:


this way all db schema modifications can be performed by schema files instead of scripts.

pizza commented on 2007-11-27 17:21

Okay, we need to do this:

1) Add a "serial number" to the database, or adapt the current 'version' table to be more flexible.
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)
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....

pizza commented on 2007-11-27 17:38

The initial installer rewrite will do EverythingRight(tm), and as such will only support new installs and upgrades from 2.34.

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.

pizza commented on 2007-11-27 22:15

The plan is to generate a standard postgresql dumpfile for the "current" schema.

The output is slightly different from what our parser expects, unfortunately, so the installer needs tweaking..

pizza commented on 2007-11-28 20:32

It's checked in. TEsting to commence.

pizza commented on 2007-11-28 21:58

new installs work -- starting from a 2.34 base sql file, and applying the 2.35 upgrade to it.

I need to test out real upgrades from 2.33, and 2.34.

pizza commented on 2007-11-28 22:57

Installer is validated for the old-demo site, upgrading from 2.33 -> 2.35.

Need to re-run it for the -stable demo site.

pizza commented on 2007-11-28 23:14

We theoretically support upgrades from v2.32 now. I do NOT have any way of testing this.


Available keyboard shortcuts


Task Details

Task Editing