Changes between Version 14 and Version 15 of SchemaEvolution


Ignore:
Timestamp:
05/28/2006 05:59:07 PM (9 years ago)
Author:
oggie rob
Comment:

Added comment on model version number problems

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolution

    v14 v15  
    309309.. _TheProcessOfDatabaseRefactoring: http://www.agiledata.org/essays/databaseRefactoring.html
    310310.. _RefactoringDatabases: http://www.bookpool.com/sm/0321293533
     311
     312Why something different
     313-----------------------
     314
     315I agree with "Something Completely Different" above. I worked on a Java-based product that used a similar approach to numbered schema versioning (although we worked with serialized objects in the backend instead of a relational DB). We had trouble merging changes with conflicting version numbers. This was not initially a huge problem for us, because we had very little overlap within and between our projects. However, the times that it happened it was a big deal, and as soon as we started real parallel development, it became a critical issue. I think for Django teams this is a killer, because deployments are so quite common and testing tends to be a part of the developers roles.
     316
     317An example is svnA user creates schema version 5, while concurrently svnB makes version 5. Everything is fine until merge, then either user has an unusable database. This is bad enough, but consider branches! It gets ugly, and can easily break the production database at unexpected times.
     318
    311319}}}
Back to Top