Improvements/Migrations - Revision history

Sallain at 21:55, 11 February 2020

2020-02-11T21:55:28Z

Hbecker: Add development documentation category

2017-03-10T19:59:31Z

Add development documentation category

Hbecker: /* Status */ Update PRs

2017-02-06T22:31:19Z

Status: Update PRs

Hbecker: /* Status */ Completed

2017-02-06T22:30:03Z

Status: Completed

Hbecker: Finish write-up, add conclusion

2016-02-02T18:08:27Z

Finish write-up, add conclusion

Hbecker: Initial summary

2016-02-02T01:06:58Z

Initial summary

New page

== 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 ([https://github.com/artefactual/archivematica/pull/377 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 [https://docs.djangoproject.com/en/1.7/topics/migrations/ 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

← Older revision		Revision as of 21:55, 11 February 2020
Line 1:		Line 1:
		+	<div style="padding: 10px 10px; border: 1px solid black; background-color: #F79086;">This page is no longer being maintained and may contain inaccurate information. Please see the [https://www.archivematica.org/docs/latest/ Archivematica documentation] for up-to-date information. </div> <p>

	== User Story ==		== User Story ==

← Older revision		Revision as of 19:59, 10 March 2017
Line 46:		Line 46:

	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.		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.
		+
		+	[[Category:Development documentation]]

@@ Line 6: / Line 6: @@
 == Status ==
-Complete
+Complete, included in Archivematica 1.5. The Archivematica Storage Service already has Django migrations (upgraded from the previous South migrations).
-Code written ([https://github.com/artefactual/archivematica/pull/377 Pull Request]), included in Archivematica 1.5. The Archivematica Storage Service already has Django migrations (upgraded from the previous South migrations).
+Pull requests: [https://github.com/artefactual/archivematica/pull/409 Archivematica 1.5] and [https://github.com/artefactual/archivematica/pull/462 Archivematica 1.6]
 == Interest ==

@@ Line 2: / Line 2: @@
 == 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.
+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 ([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 ==
-Please feel free to add your organizations name to this list, if you have an interest in this improvement.
+Please feel free to add your organization's name to this list, if you have an interest in this improvement.
 == 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.
-We would like to move to [https://docs.djangoproject.com/en/1.7/topics/migrations/ Django migrations], new in Django 1.7.
+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 ===
-* + existing process
+Pros:
-* + faster in the short term to generate 1.5 packages
+* existing process
 ** how much faster?
-* - harder to move to ansible from packages
+Cons:
 ** 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
+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.
-* + 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)
+Pros:
-** - All of these bugs have to be fixed before 1.5 release
+* Easier to move to ansible from a package install
-* Code would go in the debian/postinst script
+* No hard-to-read mysql seed file that has to be re-generated for every release