Hi Pascal, On 03/30/2015 02:57 PM, Pascal Chambon wrote: > Thanks for your answers, > > l'm confused nonetheless, because their are two notions mixing up, here, > that we should probably separate: > > - the HISTORY of SQL schemas, aka "django/south migrations" > - the CURRENT STATE of SQL schemas, that I'll call "ORM Models Dump" > > Let's leave the SQL data (and its migrations) out of the equation > please, here i'm only caring about the structure of data, the schemas, > and their corresponding SQL DDL. > > I completely understand and agree that migrations are the way to go to > upgrade between app version, not only because it allows adding/removing > columns (which syncdb didn't do, previously), but also doing all sorts > of on-the-fly custom conversions. > > However, what I am seeking, is not a dump of successive migrations (even > aggregated), it's an "ORM models dump", i.e a "transliteration" of > django ORM classes to their corresponding SQL CREATE statements. Just > like a "mysqldump --no-data", except that it's the logical, theoretical > schema that I want here, not the real, SQL-side one. > > I really do not believe that we need all the history of schema changes > to get this schema dump ; AFAIK, it's the django ORM models which define > the logical schema of data, not the migrations ; if a class MyUser > defines a field "my_adress", and migrations have no track of it, it's > the migrations that are wrong/incomplete, not the python code. Both > "current models" and "the sum of all migrations" are supposed to be in > sync at any time, arent they ? Custom SQL code is thus not a problem, > since we don't care about the path taken, just were we are currently.
I understand what you are saying, but your understanding is no longer correct. Migrations are (intentionally) powerful, and you are permitted to include arbitrary SQL DDL in your migrations (via the RunSQL migration). This DDL is part of your schema just as much as any DDL auto-generated by Django in a CreateModel operation is, and your code may depend on it. So if we dumped a schema directly from the models, ignoring migrations, it could be missing crucial elements of your actual schema. So it is not true that the Python models are the canonical representation of your schema, and the SQL DDL is just a translation of them. In fact, your migrations are the (only) canonical representation of your schema, which may include things (specialized indices, views, SQL functions, triggers...) that don't have any direct representation in the Python models at all. The Python models just need to be in-sync enough to generate the correct SQL for queries at run-time, but they often will not fully represent your schema. There should be only one canonical representation of your schema. This canonical representation cannot possibly be anything but your migrations, unless we removed the ability to run arbitrary DDL in migrations (which is not an option; that's too useful). Therefore, migrations are the canonical schema. Therefore, we won't introduce any way to "dump SQL schema" unless it is based on the contents of your migrations (the approach Andrew mentioned). > So if django was probably able to dump all the DDL for its ORM models in > the past, why couldn't it continue to do it ? Because in the past we did not have migrations, and we don't want two different (possibly inconsistent) canonical representations of your schema. The old way of generating SQL DDL directly from models is deprecated, and will disappear entirely in a future version of Django. The new way of generating SQL DDL from models _is_ the migrations system. Carl -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/5519BBCC.6070901%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
