bf0436a45317990e0a30b5e648b3a2f126d3d879
[dbsrgits/DBIx-Class-Historic.git] / VERSIONING.SKETCH
1 Schema versioning/deployment ideas from Jess (with input from theorbtwo and mst):
2 1) Add a method to storage to:
3  - take args of DB type, version, and optional file/pathname
4  - create an SQL file, via SQLT, for the current schema
5  - passing prev. version + version will create an sqlt-diff'ed upgrade file, such as
6   - $preversion->$currentversion-$dbtype.sql, which contains ALTER foo statements.
7 DONE
8 2) Make deploy/deploy_statements able to to load from the appropriate file, for the current DB, or on the fly? - Compare against current schema version..
9 3) Add an on_connect_cb (callback) thingy to storage.
10 DONE
11 4) create a component to deploy version/updates:
12  - is injected into the Schemas base classes
13  - it hooks itself into on_connect_cb ?
14  - when run it:
15    - Attempts or prompts a backup of the database. (commands for these per-rdbms can be stored in storage::dbi::<dbtype> ?)
16    - Checks the version of the current schema being used
17    - Compares it to some schema table containing the installed version
18    - If none such exists, we can attempt to sqlt-diff the DB structure with the schema
19    - If version does exist, we use an array of user-defined upgrade paths,
20     eg: version = '3x.'; schema = '1.x', upgrade paths = ('1.x->2.x', '2.x->3.x')
21    - Find the appropriate upgrade-path file, parse into two chunks:
22     a) the commands which do not contain "DROP"
23     b) the ones that do
24    - Calls user callbacks for "pre-upgrade"
25    - Runs the first set of commands on the DB
26    - Calls user callbacks for "post-alter"
27    - Runs drop commands
28    - Calls user callbacks for "post-drop"
29  - The user will need to define (or ignore) the following callbacks:
30   - "pre-upgrade", any code to be run before the upgrade, called with schema object, version-from, version-to, db-type .. bear in mind that here any new fields in the schema will not work, but can be used via scalarrefs.
31   - "post-alter", this is the main callback, at this stage, all old and new fields will be available, to allow data migration.
32   - "post-drop", this is the clean-up stage, now only new fields are available.
33