Desktopcouch needs a simple data migration mechanism
Bug #675590 reported by
Eric Casteleijn
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
desktopcouch |
Fix Released
|
Medium
|
Vincenzo Di Somma | ||
desktopcouch (Ubuntu) |
Fix Released
|
Medium
|
Vincenzo Di Somma |
Bug Description
When changes are made to the way data is stored in couchdb by desktopcouch or any of the applications that use it, we need to provide a way to upgrade data where needed. We'd prefer this to be a simple mechanism that will have minimal impact on overall performance, and will be relatively easy to use by application developers.
Related branches
lp:~vds/desktopcouch/simple_migration_infrastructure
- Chad Miller (community): Approve
- Manuel de la Peña (community): Approve
- Eric Casteleijn (community): Approve
-
Diff: 308 lines (+263/-1)5 files modifiedbin/desktopcouch-get-port (+5/-0)
desktopcouch/migration/__init__.py (+80/-0)
desktopcouch/migration/tests/__init__.py (+1/-0)
desktopcouch/migration/tests/test_migration.py (+176/-0)
runtests.py (+1/-1)
Changed in desktopcouch: | |
assignee: | Eric Casteleijn (thisfred) → Vincenzo Di Somma (vds) |
Changed in desktopcouch: | |
status: | In Progress → Fix Committed |
Changed in desktopcouch (Ubuntu): | |
status: | New → In Progress |
importance: | Undecided → Medium |
assignee: | nobody → Vincenzo Di Somma (vds) |
milestone: | none → natty-alpha-1 |
Changed in desktopcouch (Ubuntu): | |
milestone: | natty-alpha-1 → natty-alpha-2 |
Changed in desktopcouch: | |
status: | Fix Committed → Fix Released |
Changed in desktopcouch (Ubuntu): | |
status: | In Progress → Fix Released |
To post a comment you must log in.
The design Vincenzo and I came up with so far:
For each data migration that needs to happen, create a view that checks for the presence of the old feature, or the absence of the new feature on each document, and register a migration script or class in the code to deal with the documents that the view returns. Then on couchdb startup, run the migration views and fix any resulting documents.
We will need a way to register the views/migration scripts agains specific databases, or all databases. (Views should be smart enough that they ignore anything that is not a desktopcouch records, so that we don't mess with any non-desktopcouch data in the case we're talking to all dbs.)