[RFC] Migrations

[DavidIQ]

Migrations is not just about extensions, its also about being able to release further olympus releases after an ascreaus release (security issues etc.).

What do Olympus releases have anything to do with Ascareaus releases? If there is a security issue that needs to be addressed in Olympus we would still have to do a release as we currently do. How does this Migrations RFC change this?

[MichaelC]

Because the current system cannot handle the following:

3.0.11 Release DB Change
3.1.0 Release DB Change
3.0.12 Release DB Change
3.1.1 Release DB Change - Same DB Change as 3.0.12
3.1.2 Release DB Change

Senario:
The current system says 'Hey, we are on 3.0.11, we need to upgrade to 3.1.1 with everything in between (3.0.12, 3.1.0, 3.1.1)'.
Problem:
The security db fix was applied in both 3.0.12 and 3.1.1
If you say, fine for the 3.1.1 release skip the 3.0.12 schema, then what if your updating from 3.0.12?

The problem comes when we apply a fix to both branches, then the user decides to update. The changes are applied twice. Migrations is becoming more commonly used as the source of versioning a database structure. In the cast of migrations, there would be a file migration1350661968.php containing that fix, and would therefore only be applied once (as there is just 1 migration file). The DB keeps track of which migrations have been applied. It operates by applying each migration file rather than updates to the schema for each version.

Due to such clashes, we cannot make another olympus release after 3.1-Alpha unless olympus and ascreaus have migrations (which is a reason why there must be a 3.0.12 after migrations has been finished (probably before 3.1 even reaches alpha))

Best place (from my POV) to find out about migrations would be symfony's explanation on how to use them through the doctrine migrations bundle here.

[DavidIQ]

Far as I know and can see from your explanation, UMIL does the same exact thing when you specify the version in the install file:

Code: Select all

$versions = array(
	'3.0.12' => array(
              //Do some changes for 3.0.12
	),
	'3.1.0' => array(
              //Do some changes for 3.1.1
	),
);

The point being made here is that if nobody's going to be completing Migrations anytime soon then we should just go with something that already works (UMIL).

[MichaelC]

You don't seem to understand.

1) This is not UMIL, this is core phpBB updating. We've already established UMIL is an alternative to migrations extension-wise.
2) You've just proved my point. With migrations its just said/done once as it applies the migration, not the changes for that version. With the current system its repeated: https://gist.github.com/0724fdbbe6b0afe489e8

The first being what we would have (it repeated in two different versions).
The second is what we'd have with migrations (one file, all files get applied).

So there one per change, not per version.

[EXreaction]

Even if schema changes are required in 3.0, it's still possible to just check for those schema changes when performing that part of the update for 3.1 (this is done a lot currently in the db update file). It's a little more work, but I don't think it's a big deal because the likelihood of schema changes on 3.0 is rather small.

DavidIQ, the problem with UMIL is that, after updating to 3.1, if another 3.0.x is added, UMIL wouldn't perform those instructions (just stuff newer than 3.1).

[DavidIQ]

Ah that's right. So then I agree with what nn- and bantu said in EXreaction's PR that perhaps UMIL should also be added into the core if Migrations are going to be back-ported into 3.0.

[EXreaction]

From the way nils made it sound in IRC, he wanted to use parts of umil for the backend. I could go ahead and integrate umil into phpbb and update it for 3.1 if that sounds good.

The only thing about umil is that it was designed to be self-contained, id assume we want it to be more organized with the rest of the core if its integrated then?

[MichaelC]

From the way nils made it sound in IRC, he wanted to use parts of umil for the backend. I could go ahead and integrate umil into phpbb and update it for 3.1 if that sounds good.

The only thing about umil is that it was designed to be self-contained, id assume we want it to be more organized with the rest of the core if its integrated then?

I believe the ideas was always to use migrations to add sequencing & organisation of how/when to perform the updates, but UMIL would perform the updates.

[EXreaction]

What's the status naderman?

[Oleg]

includes/db/migration is the wrong place for migration files. Should be install/migration.

I would also insist on a timestamp for all migration files. E.g. YYYYMMDD_HHMM_name.php. Timestamp should be in UTC. Name may still be required to be unique although with extensions that might present a challenge.