On Thursday, June 23, 2016 at 12:12:51 AM UTC+2, Shai Berger wrote: > > > Thanks for this thoughtful clarification. I think I understand your > position > much better now. If
Thanks for reading, Shai. I know my English is far from perfect, so I appreciate your involvement. I understand correctly, there are two issues you find with > migrations: > > - They are designed to deal with schema changes, while you'd rather have a > tool for one-time schema generation; > > In most cases, yes. But I see now new possibilities (I'll wrote about my thoughts another time) > - Migration files are Python code with potential dependencies, while you > prefer > your schema (and even data) changes to be expressed in pure SQL. > > This is just one of all reasons, but yes. > > It was very handy to prototype the app layer and generate DDL. Then DDL > was > > used directly in db schema management system. > > - Isn't it, then, possible to generate a schema by evolving it while > prototyping on your development machine, and when done, use the db schema > management tools to extract the DDL directly from the database? Isn't it > actually better than generating DDL in Python, according to your views? > > It depends on what "better" means. Django is very helpful for generating initial sqls, especially for indexes and foreign keys. Further changes we make using db mgmt tool. This is part of our workflow for years - prototype python code, make some tests, generate sql for new models, make additional sqls (views, triggers, etc), finish feature, send to qa, deliver. Writing Django models in Python is faster than writing plain SQL or using db GUI tools. And we are writing them just only once. Using other DDL tools and making diffs between databases will slow down our workflow. We're accepting Django's table/columns/m2m/constraints naming conventions, and we're accepting all limitiations. The db schema is compatible with Django. We didn't found faster method yet (except Django's changes autodetection). > - But Andrew's patch[1] completely ignores any existing migration files, > bypassing all problems related to migration files as well as the "journey > through winding road". If it will not use migration files when they already exists, it sounds ok. I know too little about migations internals, so I can't be sure for now. > What he suggests is to use the migrations > infrastructure to generate just the SQL for the difference from "nothing" > to > "current models" (so, no "model state changes" either). I thought that diff from nothing to current will be achieved by applying migrations sequentially. It sound ok if this will be ommitted. > Even the issue of > SchemaEditor's deferred_sql is handled by "collect_sql" mode, as you've > already noted yourself (and by the way, the deferring mechanism is > required in > order to resolve circular dependencies between models). Do you have other > objections to this patch's approach? > Well.. yes and no. I just have almost finished patch which brings back sql* commads based directly on SchemaEditor. The difference is in ommitting django.db.migrations completely, so there is straightforward path to get current db state (without using whole complex migrations abstraction layer), less dependencies and less risk of failure due to some db.migrations issues/regression. The drawback is that output sql may little differ comparing to output from migrations-based alternative, even if both methods will use same SchemaEditor. There also will be new association to SE, so further changes of SE will require attention not only to migrations subsystem. Please share your thougths because I can miss something. I don't how important is to use django.db.migrations for every sql-related use case. It is about your preferences and design decisions. For me it is not a problem until both (sql* and migrations) depends on same sql factory (SchemaEditor here). For me, the sql* world is quite different from the migrations, and it is ok to not mix up these two things. The cost of maintaining additional association seems to be low, but I might be wrong. The "dead end" term used by me in the context of Andrew's patch was mostly related to the migration files issues. Having already better knoweldge I will look at his pull rq again. Marcin -- 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 https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2c4cbc51-d9e3-401e-a8ab-fdb3e35d9c9a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
