Changes between Version 43 and Version 44 of SchemaEvolution


Ignore:
Timestamp:
08/01/2008 11:57:52 AM (7 years ago)
Author:
programmerq
Comment:

"it's" is a contraction. "its" is possesive.

Legend:

Unmodified
Added
Removed
Modified
  • SchemaEvolution

    v43 v44  
    383383
    384384To be honest I would not like a system that tried to cater to Carol. She is an idiot and needs to learn more. If the answer to
    385 something is "you don't have to know what you are doing" then its not a good answer. Django.. to use Django, its not that you don't
    386 have to know a lot, its that you have less work to do. Everything is faster, not stupider.
     385something is "you don't have to know what you are doing" then it's not a good answer. Django.. to use Django, it's not that you don't
     386have to know a lot, it's that you have less work to do. Everything is faster, not stupider.
    387387
    388388Really I'm uncomfortable catering to Alice either. If she can't read SQL, tell her not to use a database. I say start off with a system
     
    405405-- Anders Hovmöller
    406406
    407 Since 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.
     407Since 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. It's 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 it's 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
    409409
Back to Top