[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
naderman
Consultant
Posts: 1727
Joined: Sun Jan 11, 2004 2:11 am
Location: Karlsruhe, Germany
Contact:

Re: [RFC] Migrations

Post by naderman » Wed Mar 14, 2012 10:19 pm

Yes it already uses db_tools, what it requires is extra functionality (like adding permissions) which is present in UMIL and doesn't belong into db_tools.

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

Re: [RFC] Migrations

Post by EXreaction » Wed Oct 10, 2012 4:09 pm

I would suggest that this be pushed to 3.2.

Instead, to provide extensions with the capability to perform database updates, I suggest UMIL come as part of the core for now, and a standard format be designed where during enable/disable/purge for extensions, an extension would have a variable in a main class or a separate file with just the installation data (schema changes) variable. This could be done with very little work and would allow us to start thinking about releasing a 3.1 beta.

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

Re: [RFC] Migrations

Post by MichaelC » Wed Oct 10, 2012 4:25 pm

We can't think about releasing alpha until template events are done; at which point, if migrations seems a long way off then I suppose this could be re-visited. For now however there is no point to discussing it. :)
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.

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

Re: [RFC] Migrations

Post by Oleg » Wed Oct 10, 2012 8:39 pm

Extensions need to be able to perform database changes during their installation/deinstallation. This is a requirement for 3.1. So far migrations have been proposed as the most desirable/efficient way of achieving this, and there is a partial PR posted.

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

Re: [RFC] Migrations

Post by EXreaction » Thu Oct 11, 2012 1:31 am

Oleg wrote:Extensions need to be able to perform database changes during their installation/deinstallation. This is a requirement for 3.1. So far migrations have been proposed as the most desirable/efficient way of achieving this, and there is a partial PR posted.
I do not see why this cannot be done with UMIL, as I explained above. I know UMIL is usually used along with a dedicated file for handling installations/updates (the UMIL Auto framework), but there is no reason installation files need to be designed that way, UMIL from the core just takes a couple of variables for input and performs all the changes to the database that are required. UMIL Auto, what mods typically use, is just a GUI framework on top of that core set of variables.

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

Re: [RFC] Migrations

Post by EXreaction » Mon Oct 15, 2012 3:53 am

Since template events is now (I think) done, this is the only major thing holding 3.1 back.

Since it seems like one of the biggest reasons for migrations is for extensions, if I provide an alternative way for extensions to be installed/uninstalled with UMIL automatically when enabled/purged, would this be of interest so we may push migrations to 3.2 and get 3.1 out the door?

User avatar
imkingdavid
Registered User
Posts: 1050
Joined: Thu Jul 30, 2009 12:06 pm

Re: [RFC] Migrations

Post by imkingdavid » Mon Oct 15, 2012 1:53 pm

I would rather we do it how we want it permanently now instead of changing systems later.

That is, unless we can make the extension "API" (i.e. the format extension authors use) the same regardless of the processor (UMIL, migrations system etc.) so that we can later implement the migrations backend without breaking extensions.
I do custom MODs. PM for a quote!
View My: MODs | Portfolio
Please do NOT contact for support via PM or email.
Remember, the enemy's gate is down.

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

Re: [RFC] Migrations

Post by EXreaction » Mon Oct 15, 2012 2:30 pm

That would be ideal, but as long as we include UMIL going forward, we wouldn't have to break anything when we add migrations.

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

Re: [RFC] Migrations

Post by MichaelC » Mon Oct 15, 2012 2:58 pm

imkingdavid wrote:I would rather we do it how we want it permanently now instead of changing systems later.

That is, unless we can make the extension "API" (i.e. the format extension authors use) the same regardless of the processor (UMIL, migrations system etc.) so that we can later implement the migrations backend without breaking extensions.
You don't seem to quite understand the concept of migrations. Migrations you have 1 file which has up and down sql instructions. You can install migrations in any order and miss some out. Thats the point of them. UMIL is very different.

Anyway, instead of saying lets just not bother with it, perhaps you could ask Nils what you can do to help out with getting it done asap?
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 » Mon Oct 15, 2012 4:35 pm

Really the only difference between UMIL and migrations is that with migrations you can be working on multiple projects and merge them together without interference and where everyone in different states should be able to update without issues (for example, if I am working on X locally and Y is merged to develop, when I merge Y to X, Y should be installed correctly on a database update). UMIL is not designed to handle distributed work, you must declare updates to be specific versions that go in order (so if you'd merge Y in the above example, you'd have to modify the install file for X to have yours be a slightly higher version and then also hackishly install the updates required).

This is very beneficial for phpBB development, but I'd argue that it's not quite so important for mods/extensions because they typically have less distributed development.

UMIL could actually probably be modified to do this fairly easily as well, it just would be required that UMIL is a part of the core because it would require an additional table in the database (which is not something that would hold it back now anyways if we wanted to do this).

I do not really think writing something from scratch that does everything UMIL does, but a bit more, is a good use of time. UMIL took a good bit of effort to provide a friendly install/update/uninstall environment so you could go from what is our database_update.php, to a simple array, like this: https://github.com/EXreaction/User-Blog ... tabase.php

A lot of the things that were done to make database changes friendly will need to be redone of we were to start from scratch.

Post Reply