-
Notifications
You must be signed in to change notification settings - Fork 398
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use PHP in migration files (remove SQL statements) #608
Comments
Another benefit would be that it's cross-database compatible as long as you don't use SQL queries. Makes it possible to fire migration files against different database vendors. Also migration files aren't worthless anymore when a project switches to a different database vendor. |
👍 |
nice idea 👍 |
👍 |
1 similar comment
+1 |
A big 👍 here especially for the fact that migrations will be agnostic ; this is really cool when the DBMS used locally is no the same in production plus its easier to review/debug. |
👍 but maybe we should still keep the "old" migration management, so it's easier to migrate from your propel1 project |
Sorry if I'm missing something but what would be the point ? If you are upgrading, your migrations have been run anyway. |
In our vagrant-setup we're importing a static database backup every time we setup a new vagrant machine. After that we run our migrations over this backup so the dev-database is on the latest version. In case this isn't a common use case, we can just drop the old migration management. :-) |
It will be backwards-compatible 👯 |
Nice 👍 |
👍 It would be fantastic if there would be support for triggers and procedures and other objects too 👼 |
+1 |
Maybe nice to look into this project, sounds like this already has what you need https://github.com/lulco/phoenix |
For framework-agnostic migrator, I suggest phinx: it's used in Eventum since 3.2.0 (2017-05-20): |
It doesn't make sense to use another library since Propel has already everything needed. It would be much much more work to remove that and use another library entirely, plus it would have a lot of duplicate code. |
While I'm trying out some fixes for the migration part I came over migration files generated from SQLite. I opened those files to see which stuff has been changed. Since SQLite doesn't support much
ALTER TABLE
queries we had unfortunately to develop a workaround with creating a temporarily table, move data, remove old, rename temporarily to final table etc.Example:
Not really good to read or to extend. Basically, it's unable to review that migration file. This is what led me to the idea of having migration files based on PHP, not SQL. Actually the same approach as Phinx'
Since we already have model classes and model comparator we would only need to have a class that generates PHP calls based on a
DatabaseDiff
. Anything else is already on-board.Example:
The change in the migration class would be marginal. We only pass a clone of our current $schema in the real database and see what has been changed by
get*SQL
(should be also renamed then) to the origin by callingDatabaseComparator
at it. We generate in addition to the custom defined SQL all queries from the returningDatabaseDiff
and thats it.If someone prefers the old way of migration files I could make it optional available via command option.
Would max. 1 day work - I'd do it and schedule it to the first beta release if all agree. Any thoughts?
The text was updated successfully, but these errors were encountered: