Improvements/Migrations

From Archivematica
< Improvements
Revision as of 20:06, 1 February 2016 by Hbecker (talk | contribs) (Initial summary)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

User Story

As a developer, I want to automatically generated changes to the database. As a systems administrator, I want more reliability when upgrade and downgrading Archivematica.

Status

Code written (Pull Request), being considered for inclusion in Archivematica 1.5 or 1.6.

Interest

Please feel free to add your organizations 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.

dpkg

  • + existing process
  • + faster in the short term to generate 1.5 packages
    • how much faster?
  • - 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

Django migrations

  • + Easier to move to ansible from a package install
  • + No hard-to-read mysql 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)
  • - 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
  • Code would go in the debian/postinst script