[dbsrgits/DBIx-Class-Historic.git] / VERSIONING.SKETCH

Schema versioning/deployment ideas from Jess (with input from theorbtwo and mst):
1) Add a method to storage to:
 - take args of DB type, version, and optional file/pathname
 - create an SQL file, via SQLT, for the current schema
 - passing prev. version + version will create an sqlt-diff'ed upgrade file, such as
  - $preversion->$currentversion-$dbtype.sql, which contains ALTER foo statements.
DONE
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..
3) Add an on_connect_cb (callback) thingy to storage.
DONE
4) create a component to deploy version/updates:
 - is injected into the Schemas base classes
 - it hooks itself into on_connect_cb ?
 - when run it:
   - Attempts or prompts a backup of the database. (commands for these per-rdbms can be stored in storage::dbi::<dbtype> ?)
   - Checks the version of the current schema being used
   - Compares it to some schema table containing the installed version
   - If none such exists, we can attempt to sqlt-diff the DB structure with the schema
   - If version does exist, we use an array of user-defined upgrade paths,
    eg: version = '3x.'; schema = '1.x', upgrade paths = ('1.x->2.x', '2.x->3.x')
   - Find the appropriate upgrade-path file, parse into two chunks:
    a) the commands which do not contain "DROP"
    b) the ones that do
   - Calls user callbacks for "pre-upgrade"
   - Runs the first set of commands on the DB
   - Calls user callbacks for "post-alter"
   - Runs drop commands
   - Calls user callbacks for "post-drop"
 - The user will need to define (or ignore) the following callbacks:
  - "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.
  - "post-alter", this is the main callback, at this stage, all old and new fields will be available, to allow data migration.
  - "post-drop", this is the clean-up stage, now only new fields are available.
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.
4386b954	7	DONE
fddfcdda	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..
fddfcdda	9	3) Add an on_connect_cb (callback) thingy to storage.
4386b954	10	DONE
fddfcdda	11	4) create a component to deploy version/updates:
4386b954	12	- is injected into the Schemas base classes
fddfcdda	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