[RFC] Migrations
Re: [RFC] Migrations
Sounds good. IIRC, migrations are the last obstacle for 3.1 ALPHA?
Above message may contain errors in grammar, spelling or wrongly chosen words. This is because I'm not a native speaker. My apologies in advance.
- EXreaction
- Registered User
- Posts: 1555
- Joined: Sat Sep 10, 2005 2:15 am
Re: [RFC] Migrations
Correct, once they are merged we plan on having a couple of weeks to get other items merged for 3.1 yet, then release an alpha.
- EXreaction
- Registered User
- Posts: 1555
- Joined: Sat Sep 10, 2005 2:15 am
Re: [RFC] Migrations
I believe the core migrations system is now finished.
https://github.com/phpbb/phpbb3/pull/1180
There is some work to do on the migrations data (replaces database_update.php with a migrations update script):
https://github.com/phpbb/phpbb3/pull/1183
There is also a little work to make it easier for extensions to run migrations.
https://github.com/phpbb/phpbb3/pull/1180
There is some work to do on the migrations data (replaces database_update.php with a migrations update script):
https://github.com/phpbb/phpbb3/pull/1183
There is also a little work to make it easier for extensions to run migrations.
- bantu
- 3.0 Release Manager
- Posts: 557
- Joined: Thu Sep 07, 2006 11:22 am
- Location: Karlsruhe, Germany
- Contact:
Re: [RFC] Migrations
Do migrations touch 3.0.x? Does 3.0.x database updater have to be changed to migrations?
- EXreaction
- Registered User
- Posts: 1555
- Joined: Sat Sep 10, 2005 2:15 am
Re: [RFC] Migrations
Migrations don't apply to 3.0.
The only thing that needs to be done for 3.0 is the migrations table needs to be created and populated with the appropriate migration identifiers (in install and database update).
http://tracker.phpbb.com/browse/PHPBB3-11317
This is to make upgrades between 3.0 and 3.1 clean and easy.
The only thing that needs to be done for 3.0 is the migrations table needs to be created and populated with the appropriate migration identifiers (in install and database update).
http://tracker.phpbb.com/browse/PHPBB3-11317
This is to make upgrades between 3.0 and 3.1 clean and easy.
- DavidIQ
- Customisations Team Leader
- Posts: 1904
- Joined: Thu Mar 02, 2006 4:29 pm
- Location: Earth
- Contact:
Re: [RFC] Migrations
Why does it matter if it's in 3.0 or not? Wouldn't the update script just create it on its own?
- EXreaction
- Registered User
- Posts: 1555
- Joined: Sat Sep 10, 2005 2:15 am
Re: [RFC] Migrations
It's a complicated situation.
We need to know what migrations are effectively installed already when updating from 3.0 to 3.1.
We could mostly do this by comparing the phpBB version, but there could be a problem. Here are a few scenarios:
3.0.12 is released
3.1.0 is released
User updates from 3.0.12 (or any version prior):
3.0.12 is known by 3.1.0 migrations and therefor we can map what migrations have been effectively installed already.
3.1.0 is released
3.0.12 is released
User updates from 3.0.12:
3.0.12 is not known by 3.1.0 migrations and therefor we have no idea what migrations have effectively been installed.
In the second case, if 3.0.12 added the migrations table and the migration identifiers that have been effectively installed, we can update without any problems (assuming the schema hasn't changed in a way in 3.0.12 that the older 3.1.0 code throws errors).
We need to know what migrations are effectively installed already when updating from 3.0 to 3.1.
We could mostly do this by comparing the phpBB version, but there could be a problem. Here are a few scenarios:
3.0.12 is released
3.1.0 is released
User updates from 3.0.12 (or any version prior):
3.0.12 is known by 3.1.0 migrations and therefor we can map what migrations have been effectively installed already.
3.1.0 is released
3.0.12 is released
User updates from 3.0.12:
3.0.12 is not known by 3.1.0 migrations and therefor we have no idea what migrations have effectively been installed.
In the second case, if 3.0.12 added the migrations table and the migration identifiers that have been effectively installed, we can update without any problems (assuming the schema hasn't changed in a way in 3.0.12 that the older 3.1.0 code throws errors).
Re: [RFC] Migrations
So maybe there should be a condition set for all 3.0.x releases released after 3.1, that migration must be merged to 3.1 prior to relasing that 3.0.x version and new 3.1 version should be released along with new 3.0.x version. Maybe it breaks current versioning principles, it is just an idea...EXreaction wrote:...3.1.0 is released
3.0.12 is released
User updates from 3.0.12:
3.0.12 is not known by 3.1.0 migrations and therefor we have no idea what migrations have effectively been installed.
In the second case, if 3.0.12 added the migrations table and the migration identifiers that have been effectively installed, we can update without any problems (assuming the schema hasn't changed in a way in 3.0.12 that the older 3.1.0 code throws errors).
Re: [RFC] Migrations
How do you plan to address the problem that is updating from 3.0.x (where x < 12) to 3.1.x that the migrations table would still need adding with the appropriate migrations depending on which version the update is being done from?
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
- EXreaction
- Registered User
- Posts: 1555
- Joined: Sat Sep 10, 2005 2:15 am
Re: [RFC] Migrations
That is one option I had in mind, but I am not sure if that is something we want to be restricted by.Senky wrote:So maybe there should be a condition set for all 3.0.x releases released after 3.1, that migration must be merged to 3.1 prior to relasing that 3.0.x version and new 3.1 version should be released along with new 3.0.x version. Maybe it breaks current versioning principles, it is just an idea...
I have a list of phpBB version numbers and the migrations that were applied for those versions. If the migrations table does not exist I automatically fill it with these migrations based on what phpBB version it was.MichaelC wrote:How do you plan to address the problem that is updating from 3.0.x (where x < 12) to 3.1.x that the migrations table would still need adding with the appropriate migrations depending on which version the update is being done from?
Right now I am thinking the safest option might be to add a method to each migration, is_installed, which would be able to run custom code to check if the migration was effectively installed (in which case we'd just add the migration data to the migration table and be done). I think this might be best for us and extension authors who update their mods for 3.1.