zeitgeist team mailing list archive

[Markus Korn <thekorn@xxxxxx>]

Public bug reported:

We have to discuss how to support versions jump in the upgrade path of
our db schema, like from ("core", 0) to ("core", 2). This becomes even
more important when we reach the next version.

For me there are two solution:
1.) write 'dummy' upgrade scripts, like core_0_2.py, which do not more than running core_0_1.run() and core_1_2.run() one after another
2.) add some magic to sql._do_schema_upgrade() which automatically tries to find an upgrade path and run the 'shortest' possible one.

There is an issue with both solutions: right now the upgrade mechanism
is designed in a way that after each data upgrade the schema upgrade is
done. In both solutions the schema upgrade will be done *after* the full
upgrade path. This can be handled by solution 1.) in the sanest possible
way, the downside is that 1.) does not scale well for big numbers of
schema versions around.

Any Ideas?

** Affects: zeitgeist
     Importance: Medium
         Status: New

** Changed in: zeitgeist
   Importance: Undecided => Medium

-- 
Upgrade of the db schema strategy for version jumps
https://bugs.launchpad.net/bugs/643303
You received this bug notification because you are a member of Zeitgeist
Framework Team, which is subscribed to Zeitgeist Framework.

Status in Zeitgeist Framework: New

Bug description:
We have to discuss how to support versions jump in the upgrade path of our db schema, like from ("core", 0) to ("core", 2). This becomes even more important when we reach the next version.

For me there are two solution:
1.) write 'dummy' upgrade scripts, like core_0_2.py, which do not more than running core_0_1.run() and core_1_2.run() one after another
2.) add some magic to sql._do_schema_upgrade() which automatically tries to find an upgrade path and run the 'shortest' possible one.

There is an issue with both solutions: right now the upgrade mechanism is designed in a way that after each data upgrade the schema upgrade is done. In both solutions the schema upgrade will be done *after* the full upgrade path. This can be handled by solution 1.) in the sanest possible way, the downside is that 1.) does not scale well for big numbers of schema versions around.

Any Ideas?