View Issue Details

IDProjectCategoryView StatusLast Update
0020351mantisbtupgradepublic2016-01-25 12:22
Reportervboctor Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version1.3.0-rc.1 
Summary0020351: Enable schema updates in more than one branch
Description

We currently can only change schema on a single branch due to having a single schema version. Should we have enable the ability to track specific schema change steps enabling us to add schema changes in 1.2.x even though we have already release 1.3.x releases (or pre-releases) with schema changes?

See 0020340 for an example where this is needed.

I would rather have the option to add a schema change whenever it makes sense or there is need a need to do so.

TagsNo tags attached.

Relationships

related to 0020340 closeddregad Attachment is saved to disk and database at the same time 

Activities

dregad

dregad

2015-12-07 09:50

developer   ~0052041

Last edited: 2016-01-25 12:18

Copying note from 0020340:0052040

move (in 1.3.x) to a model where we track upgrade steps by an id rather than a sequence number

Well, I would argue that a sequence number is an ID...

Joke aside, I'm not seeing that much benefit of switching from a numeric, sequential ID to a string. I find it useful to have an ID which both identifies the upgrade step as well as where it belongs in the sequence. Furthermore, it would become complicated to identify which steps have been applied, when, and in which sequence.

That being said, maybe the ID doesn't need to be strictly sequential. In other words, as an alternative to your suggestion, we could "reserve" a block of upgrade steps when we switch to a new major version, allowing more flexibility for required schema changes within a minor release.

For example, an hypothetical 2.0.0 schema.php could look like this:
$g_upgrade[201] = array( 'CreateIndexSQL', [...]

Release marker: 1.3.0

upgrade steps 202..219 are reserved for 1.3.x releases

$g_upgrade[220] = [...]

Release marker: 2.0.0

The problem with this approach is that it would need some special processing to cover the following scenario :

  • user is running 2.0.0
  • we change 1.3.0 schema (e.g. adding step 202), release 1.3 and port the change to 2.x
  • we release 2.1.0
  • user upgrades to 2.1.0
    Current version of the installer would not do anything.
vboctor

vboctor

2016-01-25 12:22

manager   ~0052377

@dregad, that is why I think we need a model that provides the following:

  1. A cheap way to identify an upgrade is needed.
  2. A way to identify the upgrade steps that haven't executed.
  3. A way to identify the order by which we should execute the steps that should be executed.

The order of defining the upgrade steps in schema.php (or array index) can provide 3

A step id and a table that tracks steps would be needed for 2. That is a model that we used in the past.

count(upgrade_steps_table) == # of steps in schema.php would provide 1