Changes between Version 4 and Version 5 of BluePrintDatabaseMigration

Timestamp:

03/10/11 14:02:52 (14 years ago)

Author:

Pat Tressel

Comment:

--

BluePrintDatabaseMigration

@@ -22 +22 @@
 * Determine which changes will be handled by Web2py without assistance.
 
-* For more significant changes, attempt to figure out how to convert from old to new schema.  For instance:
+* For more significant schema changes, attempt to figure out how to convert from old to new schema.  For instance:
  * Attempt to match renamed tables by their fields, and renamed fields by their characteristics.  Attempt to match fields moved out to new tables by names and characteristics.
  * Determine if type changes might be automated, or partly automated (e.g. if a field's type changes from text to datetime).
+
+* Catalog differences in the initial contents of the database.
+ * Attempt to identify which records are no longer included, which are new, and which are modified.
+
+* Determine if there will be changes that must be performed or verified by a human after conversion. (E.g. in the datetime conversion example, it is possible that some conversions will fail -- these will likely need to be fixed up by hand.)
 
 * Provide a gui that shows the schema changes and suggested fixups.  Allow the user to:
  * Confirm or alter matching of renamed elements.
  * Say how new fields should be populated from old ones.
- * Provide a migration script.
+ * Say how data with type changes should be transformed.
+ * Provide a migration script for more complex conversions.
 
-* Record the operations needed to convert a populated database to match the new schema and new initial contents across each revision.
+* Devise a way to record the operations needed to convert a database from one revision to the next.
+
+* Provide the mechanism for actually converting a database from one revision to the next.  For instance:
+ * Dump or back up the current database as a precaution.
+ * Make a dump to use in the conversion process.
+ * Determine if there is data that is affected by the changes.
+  * Is there data in the altered tables?
+  * Does anything depend on the altered initial contents?
+ * Determine which changes are better made by editing the dump, and which are better made with database operations. (Note that for each revision, it is likely that this will need to be done entirely by editing the dump, or entirely by database operations, else one would have to construct an intermediate schema to load the altered dump into, to continue conversion with database commands.)
+  * If editing the dump, do so, create a new database with the new schema, and load the modified contents.
+  * If using database operations, create a new database with the old schema, load the existing dump, and alter the database.
+
+* Provide a way for a person to do any fixups or verification needed.
+
+* Determine how the result of a conversion will be verified and tested.
 
 * Provide a way for a sysadmin who has updated their copy of Eden to run the set of conversions from their previous revision to the new revision.