[RFC] Migrations

These requests for comments/change have lead to an implemented feature that has been successfully merged into the 3.1/Ascraeus branch. Everything listed in this forum will be available in phpBB 3.1.
Post Reply
User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1836
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: [RFC] Migrations

Post by DavidIQ »

Unknown Bliss wrote: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?
Image

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Migrations

Post by 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.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1836
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: [RFC] Migrations

Post by 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).
Image

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Migrations

Post by 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.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: [RFC] Migrations

Post by 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).

User avatar
DavidIQ
Customisations Team Leader
Customisations Team Leader
Posts: 1836
Joined: Thu Mar 02, 2006 4:29 pm
Location: Earth
Contact:

Re: [RFC] Migrations

Post by 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.
Image

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: [RFC] Migrations

Post by 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?

User avatar
MichaelC
Development Team
Development Team
Posts: 889
Joined: Thu Jan 28, 2010 6:29 pm

Re: [RFC] Migrations

Post by MichaelC »

EXreaction wrote: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.
Formerly known as Unknown Bliss
psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
No unsolicited PMs please except for quotes.

User avatar
EXreaction
Registered User
Posts: 1555
Joined: Sat Sep 10, 2005 2:15 am

Re: [RFC] Migrations

Post by EXreaction »

What's the status naderman?

Oleg
Posts: 1150
Joined: Tue Feb 23, 2010 2:38 am
Contact:

Re: [RFC] Migrations

Post by 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.

Post Reply