Changes between Version 18 and Version 19 of SchemaEvolution

Timestamp:

Jul 4, 2006, 5:14:01 PM (18 years ago)

Author:

Anders Hovmöller <boxed@…>

Comment:

--

SchemaEvolution

@@ -323 +323 @@
 
 You do raise a good point regarding concurrent development with branches. It's still not possible to get rid of communication -- when it comes time to do a branch merge, discussing database schema will be mandatory. However, the tool should allow for branch merges; why not store a branch name AND a version number for each schema revision? When planning for a branch merge, one can implement a "from branch 1 version 6 to branch 2 version 3" migration. Obviously, migration points will need to be well defined, but supporting branches at least allows for the possibility.
+
+Automatic interactive db introspection that generates migration scripts
+-----------------------------------------------------------------------
+I think that the nicest way for the user that would work for 99% of the cases is an automatic and (if needed) interactive command, that will generate the migration steps it took and store them in some script. Also, it could automatically update the version number in the suggestion on migration scripts above. So for a model that changes from::
+
+        class Ticket(models.Model):
+                reporter    = models.EmailField()
+                owner       = models.EmailField()
+                stat      = models.IntegerField(choices=STATUS_CHOICES)
+
+to::
+
+        class Ticket(models.Model):
+                reporter    = models.EmailField()
+                status      = models.IntegerField(choices=STATUS_CHOICES)
+                description = models.TextField()
+
+This is one removed field (owner), one added field (description), and one renamed field (stat->status). The renamed is the trickiest one obviously since it looks like one has been deleted and another added. So in this case the user should be given the menu::
+
+        The following fields are new:
+                1 status
+                2 description
+        The following fields are not present any longer:
+                3 stat
+                4 owner
+
+        Are any of these fields a rename? [y/N] y
+        Which pair is coupled? 1, 3
+
+        The following fields are new:
+                1 description
+        The following fields are not present any longer:
+                2 owner
+
+        Are any of these fields a rename? [y/N] n
+        Warning: removing the field owner will permanently delete data. Write "delete"  and press enter to continue: delete
+        Database update complete. Modifications written to Ticket-migration-1.sql
+
+If there are only additions, then the entire menu can be totally skipped and just the additions added. If there are no renames the entire thing also becomes much shorter. I think this covers most cases, and any other cases can be handled manually by writing custom SQL migration scripts as above.
+
+Anders Hovmöller (boxed@killingar.net)
 }}}