On 08/06/12 18:16, Michael Manfre wrote: > > > On Thursday, June 7, 2012 4:16:12 PM UTC-4, Alex Ogier wrote: > > This isn't particularly robust. The SQL string generated by a > particular backend isn't considered part of any API, and might change > formatting or semantics on minor updates. Some SQL is quite > complicated and dubiously related to the particular field, such as > extra INDEX or UNIQUE constraint statements. Certain backends elide > some arguments, performing constraint checking in the application (the > sqlite backend for example just drops many constraints). In general, > you want the migrations to be DB-agnostic, and checking SQL output > loses this feature. > > > While the entire raw SQL generated by a field may be too unstable to > inspect, the underlying SQL shouldn't be completely ignored. At the very > least, the datatype needs to be inspected when freezing to detect if the > rug has been pulled out from under the ORM. > > A real world use case. Django-mssql uses the datetime datatype for > datetime fields. Several years ago, Microsoft made the recommendation > that all new work should use datetime2. A future version of django-mssql > will switch to using datetime2. It would be great if the proposed > migration framework handled that sort of switch, or at the very least > displayed a warning about the need for manual user intervention. > > The same type of problem could be encountered if a database backend > becomes unsupported and users are forced to switch to another backend > where the maintainer follows a different set of "best practices". There > are many ways of storing the same data that are all completely valid. > The most likely problem field will be IPAddressField due to varchar(15) > vs. unsigned int.
I'm not sure it's going to be sensible to have the migration framework change things when the apps themselves have not changed, only the backend - Django already does a reasonable job of abstracting types, and that will need to be slightly improved but not radically changed for this work. The situation where someone changes a database backend completely and points it at the exact same database is going to be rare - far more common (I suspect) is someone changing database server and database backend in sync, and for that you DO want to ignore the SQL completely - if I go from PostgreSQL to MySQL (heaven forbid) I don't want South thinking it should still try and use an IP column type. Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
