Changes between Version 42 and Version 43 of SchemaEvolution

07/28/2008 08:39:53 PM (10 years ago)



  • SchemaEvolution

    v42 v43  
    407407Since I am not familiar with the suggestion on database refactoring I will only comment on the evolutionary versioning approach being debated. I have been working with relational databases for more than 30 years. SQL is fine, but whey force anyone to learn it if they don't already know it or don't want to? Otherwise why does Django provide automatic Model to SQL translation for everything from initial table creation to record entries, reads, etc.? I prefer the approach of providing a script or method that defines the changes from one version of a model to the next. It would be nice to have an automated introspection tool to create a first pass at this that I can edit to be absolutely correct and then have a tool that applies the intended changes so I do not have to generate the SQL and it will work no matter what database server I am using. This approach seems MUCH easier then Rails. Its also pretty much a requirement to automate and simplify updates to existing deployed apps.  For those that love SQL, create a 2nd or optional alternative to the scripting/method approach alows the SQLphiles to use SQL.  In much the same way that Django has a variety of parameters when defining Forms or Models to control Unique, Blank, etc. I can see a similar approach in version that defines how to translate a field from a prior version to the current version and if its simply a name change, it would work the same way.  The prior column name would be changed to the new one, the data would not be translated and all will be right with the world.  It would be nice for the tool that runs the evolution method to check for data translation incompatibilities so we wont hurt ourselves too badly.  If this description was not clear, please say so because the solution seems clear and obvious to me.
    408408--Jack Oswald
     410For me the majority of time consuming database changes take place during initial development experimenting with different approaches. Most of the time this also means simply adding or changing fields. It would be great to make these changes in the simple manner of the "Automatic interactive db introspection that generates migration scripts" example above. It also seems to more closely fit the Python ethos of not getting sidetracked into the maze of doing all things for all people. As stated, it fits 99% of my needs.
Back to Top