Hi again Marcin,
Thanks for this thoughtful clarification. I think I understand your position
much better now. If 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;
- Migration files are Python code with potential dependencies, while you prefer
your schema (and even data) changes to be expressed in pure SQL.
In view of the above, your discontent at the removal of the sql* management
commands is quite obvious, but there are two issues that are still unclear to
me, and I think would be helpful if you can explain:
On Wednesday 22 June 2016 15:13:18 Marcin Nowak wrote:
> 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?
On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote:
> I will not go through the Andrew's path. It is a "dead end".
> [...]
> `sql` command should not depend on migrations, because:
> - they may be corrupted (common case with south/django migrations; they
> are unreliable)
> - achieving final state is a long journey through winding road,
> - app may not include migrations itself,
> - it is about SQL but not about managing model state/changes.
- 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". 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). 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?
Please feel free to correct me if I misrepresented your views. My goal here is
to try to help find the best way to handle the issues you raised, as I'm sure
you're not alone in your positions.
Thanks,
Shai.
[1] https://github.com/django/django/pull/4729
