Commit | Line | Data |
fddfcdda |
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 | 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.. |
8 | 3) Add an on_connect_cb (callback) thingy to storage. |
9 | 4) create a component to deploy version/updates: |
10 | - it hooks itself into on_connect_cb ? |
11 | - when run it: |
12 | - Attempts or prompts a backup of the database. (commands for these per-rdbms can be stored in storage::dbi::<dbtype> ?) |
13 | - Checks the version of the current schema being used |
14 | - Compares it to some schema table containing the installed version |
15 | - If none such exists, we can attempt to sqlt-diff the DB structure with the schema |
16 | - If version does exist, we use an array of user-defined upgrade paths, |
17 | eg: version = '3x.'; schema = '1.x', upgrade paths = ('1.x->2.x', '2.x->3.x') |
18 | - Find the appropriate upgrade-path file, parse into two chunks: |
19 | a) the commands which do not contain "DROP" |
20 | b) the ones that do |
21 | - Calls user callbacks for "pre-upgrade" |
22 | - Runs the first set of commands on the DB |
23 | - Calls user callbacks for "post-alter" |
24 | - Runs drop commands |
25 | - Calls user callbacks for "post-drop" |
26 | - The user will need to define (or ignore) the following callbacks: |
27 | - "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. |
28 | - "post-alter", this is the main callback, at this stage, all old and new fields will be available, to allow data migration. |
29 | - "post-drop", this is the clean-up stage, now only new fields are available. |
30 | |