[RFC] Migrations

[naderman]

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.

[EXreaction]

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.

[MichaelC]

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.

[Oleg]

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.

[EXreaction]

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.

[EXreaction]

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?

[imkingdavid]

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.

[EXreaction]

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

[MichaelC]

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?

[EXreaction]

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.