DB migration refactoring.

Registered by Matteo Nastasi on 2014-01-15

1. check if the current migration mechanism is able to migrate a version 1.0 DB up to latest master
2. measure how much time it takes on large datasets
3. refactor the migration mechanism:
  3.1 move from dicotomic approach "latest schema OR migrations from old db" to "original schema + migrations"
  3.2 store all versions (migration date, migration script name, ...) information in the versioning table instead of the latest
  3.3 all .sql files in the same step directory must by applied atomically
  3.4 zero filling directory step names for sensible sorting
4 enhance packaging upgrade script to ask to user what to do with the preview DB (rename and start from a empty , upgrade, if you want to backup your current version break the upgrade and perform it manually).
5 downgrade warning: if a db exists the user must be advise that the procedure destroy the current DB (performed by more recent package scripts)
6 implement automatic tests

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.