Changes between Version 18 and Version 19 of SchemaEvolution


Ignore:
Timestamp:
07/04/2006 05:14:01 PM (9 years ago)
Author:
Anders Hovmöller <boxed@…>
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolution

    v18 v19  
    323323
    324324You 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.
     325
     326Automatic interactive db introspection that generates migration scripts
     327-----------------------------------------------------------------------
     328I 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::
     329
     330        class Ticket(models.Model):
     331                reporter    = models.EmailField()
     332                owner       = models.EmailField()
     333                stat      = models.IntegerField(choices=STATUS_CHOICES)
     334
     335to::
     336
     337        class Ticket(models.Model):
     338                reporter    = models.EmailField()
     339                status      = models.IntegerField(choices=STATUS_CHOICES)
     340                description = models.TextField()
     341
     342This 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::
     343
     344        The following fields are new:
     345                1 status
     346                2 description
     347        The following fields are not present any longer:
     348                3 stat
     349                4 owner
     350
     351        Are any of these fields a rename? [y/N] y
     352        Which pair is coupled? 1, 3
     353
     354        The following fields are new:
     355                1 description
     356        The following fields are not present any longer:
     357                2 owner
     358
     359        Are any of these fields a rename? [y/N] n
     360        Warning: removing the field owner will permanently delete data. Write "delete"  and press enter to continue: delete
     361        Database update complete. Modifications written to Ticket-migration-1.sql
     362
     363If 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.
     364
     365Anders Hovmöller (boxed@killingar.net)
    325366}}}
Back to Top