Difference between revisions of "Improvements/Migrations"
Jump to navigation
Jump to search
(Initial summary) |
(Finish write-up, add conclusion) |
||
| Line 2: | Line 2: | ||
== User Story == | == User Story == | ||
| − | As a developer, I want to automatically generated changes to the database. As a systems administrator, I want | + | As a developer, I want to automatically generated changes to the database. As a systems administrator, I want to reliably upgrade and downgrade Archivematica. |
== Status == | == Status == | ||
| − | Code written ([https://github.com/artefactual/archivematica/pull/377 Pull Request]), being considered for inclusion in Archivematica 1.5 or 1.6. | + | Code written ([https://github.com/artefactual/archivematica/pull/377 Pull Request]), being considered for inclusion in Archivematica 1.5 or 1.6. The Archivematica Storage Service already has Django migrations (upgraded from the previous South migrations). |
== Interest == | == Interest == | ||
| − | Please feel free to add your | + | Please feel free to add your organization's name to this list, if you have an interest in this improvement. |
== Analysis == | == Analysis == | ||
| Line 16: | Line 16: | ||
Currently, Archivematica uses SQL files that are run by dpkg (for a package install) or a shell script (for an ansible or dev-helper install). These are complicated to write, have no error handling, and prone to failure. | Currently, Archivematica uses SQL files that are run by dpkg (for a package install) or a shell script (for an ansible or dev-helper install). These are complicated to write, have no error handling, and prone to failure. | ||
| − | We would like to move to [https://docs.djangoproject.com/en/1.7/topics/migrations/ Django migrations] | + | We would like to move to [https://docs.djangoproject.com/en/1.7/topics/migrations/ Django migrations] (new in Django 1.7) for the Archivematica 1.5 release. |
=== dpkg === | === dpkg === | ||
| − | * | + | Pros: |
| − | * | + | * existing process |
| + | * faster in the short term to generate 1.5 packages | ||
** how much faster? | ** how much faster? | ||
| − | * | + | Cons: |
| + | * harder to move to ansible from packages | ||
** If the package install already has Django migrations, then ansible doesn't have to worry about faking migrations | ** If the package install already has Django migrations, then ansible doesn't have to worry about faking migrations | ||
| + | * will report success even if only some of the upgrade SQL scripts were run | ||
=== Django migrations === | === Django migrations === | ||
| − | * | + | |
| − | * | + | Code would be added to the debian postinst script to fake dpkg-run migrations. We would only back-create migrations for 1.4.1 to 1.5.0. Any older installs of Archivematica would have to upgrade to 1.4.1, then upgrade to 1.5.0. |
| − | * | + | |
| − | * | + | Pros: |
| − | * | + | * Easier to move to ansible from a package install |
| − | + | * No hard-to-read mysql seed file that has to be re-generated for every release | |
| + | * Works better with tests, since testing and production code are the same (database not generated by dpkg SQL) | ||
| + | Cons: | ||
| + | * Prone to bugs in the short term (relating to differences in how the mysql seed files created tables vs how Django models create tables) | ||
| + | * All of these bugs have to be fixed before 1.5 release, which takes time away from other projects | ||
| + | |||
| + | == Conclusion == | ||
| + | |||
| + | We will try adding Django migrations to 1.5. If too many bugs (how many?) come up in the testing phase, we will revert to dpkg. | ||
Revision as of 13:08, 2 February 2016
User Story
As a developer, I want to automatically generated changes to the database. As a systems administrator, I want to reliably upgrade and downgrade Archivematica.
Status
Code written (Pull Request), being considered for inclusion in Archivematica 1.5 or 1.6. The Archivematica Storage Service already has Django migrations (upgraded from the previous South migrations).
Interest
Please feel free to add your organization's name to this list, if you have an interest in this improvement.
Analysis
Currently, Archivematica uses SQL files that are run by dpkg (for a package install) or a shell script (for an ansible or dev-helper install). These are complicated to write, have no error handling, and prone to failure.
We would like to move to Django migrations (new in Django 1.7) for the Archivematica 1.5 release.
dpkg
Pros:
- existing process
- faster in the short term to generate 1.5 packages
- how much faster?
Cons:
- harder to move to ansible from packages
- If the package install already has Django migrations, then ansible doesn't have to worry about faking migrations
- will report success even if only some of the upgrade SQL scripts were run
Django migrations
Code would be added to the debian postinst script to fake dpkg-run migrations. We would only back-create migrations for 1.4.1 to 1.5.0. Any older installs of Archivematica would have to upgrade to 1.4.1, then upgrade to 1.5.0.
Pros:
- Easier to move to ansible from a package install
- No hard-to-read mysql seed file that has to be re-generated for every release
- Works better with tests, since testing and production code are the same (database not generated by dpkg SQL)
Cons:
- Prone to bugs in the short term (relating to differences in how the mysql seed files created tables vs how Django models create tables)
- All of these bugs have to be fixed before 1.5 release, which takes time away from other projects
Conclusion
We will try adding Django migrations to 1.5. If too many bugs (how many?) come up in the testing phase, we will revert to dpkg.