Repository navigation
[Research] Support Doctrine Migrations #13820
Description
Implementing Migrations like this is a common approach which is used across frameworks and programming languages - we should have a look on how we can stream line or database migrations with respect to using mainstream technologies.
Activity
DeepDiver1975 commentedon Feb 2, 2015
List of doctrine commands regarding migrations:
http://www.doctrine-project.org/api/migrations/2.0/namespace-Doctrine.DBAL.Migrations.Tools.Console.Command.html
DeepDiver1975 commentedon Feb 2, 2015
http://docs.doctrine-project.org/projects/doctrine-migrations/en/latest/toc.html
PVince81 commentedon Apr 19, 2016
One of the concerns mentioned by @karlitschek about doctrine migrations is that it removes the "easy of use" for app developers, because writing migration code can be more tricky than just changing an XML file. An idea to get around this would be to provide a command "occ generate-migration-code" that reads the old and updated XML files and automatically generates the PHP code that matches the changes based on the diff. This means that app developers could still use the old approach, but would be required to run an additional command to generate the PHP code.
DeepDiver1975 commentedon Apr 19, 2016
We anyhow need to support the xml based schema for quite some releases after introduction of migrations. As a result we can simply continue to support the xml based approach for apps in case they want to do it the easy way.
A switch in the app info xml could be used to explicitly enable migrations.
karlitschek commentedon Apr 19, 2016
Yes. Maybe supporting both in the best option. We can use the xml schema for the simple cases and apps. And we could support 'manual' migration for the complex cases where it is really needed and the developer knows exactly what they are doing.
DeepDiver1975 commentedon Apr 19, 2016
I see main benefit of migrations for complex scenarios - which will in most cases be core and core related apps.
Just to give an understanding for everybody on where migrations have a greater power compared to your xml schema:
complex schema changes
Let's say there is a table (let's name it oc_activities) and we want to change a column from varchar(4000) to clob.
On Oracle we need to create new table, move data, delete old table, rename - https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:1770086700346491686
Ability to downgrade
Doctrine Migrations have the capabilities to move back and forth with individual steps.
This is on one hand very helpful for developers to test migrations but on the otherhand will give us the capabilities to allow a full downgrade after e.g. an upgrade failure.
Upgrade over multiple major releases
Because migrations are a constant stream of changes we could realize upgrade over multiple major releases.
DeepDiver1975 commentedon Apr 19, 2016
To some extend this has an impact on the current work of #24085 where repairsteps will be used for apps to execute additional migration steps before and after db schema migration.
Once introduced they collide with the upgrade and downgrade capabilities of migrations - repairsteps only move in one direction - they have no downgrade capability.
DeepDiver1975 commentedon Apr 25, 2016
@karlitschek @PVince81 since we are talking about an optional mechanism - would it make sense to push fir this in 9.1 to at least have the basic foundation in place?
karlitschek commentedon Apr 25, 2016
@DeepDiver1975 Sure. Once we have all the other prio1 and prio2 9.1 tasks finished. @cmonteroluque
MTRichards commentedon Apr 25, 2016
Concur, 9.2. Tagged as such.
PVince81 commentedon Dec 12, 2016
@DeepDiver1975 the doctrine migrations PR was tested and merged #14851. Is there anything left to do ? If not, please close all relevant tickets. Thanks.
lock commentedon Aug 3, 2019
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.