Hello all,
I've noticed that all sql* commands that were in django core management have disappeared from the latest sources.
However, even though Django now has builtin south-style migrations now, these sql* commands (especially sql-all) were priceless to debug differences between the models and the actual DB schema.
Especially as long as some django apps haven't caught up with all these recent changes - I myself ended up with missing tables after scrupulously following upgrade instructions, with "manage.py migrate" saying "all is fine".
What is the new way to dump the sql schema of currently installed django appz ? It'd maybe be worth that I provide a doc patch to inform users about it.
If there is none, is there an agreement to restore at least sqlall and sqlclear ?
Also what was the reasoning behind, on the first, place, blocking access to these utilities in django1.7 (they seemed to work, when I forced them), and now removing them ? A simple warning about the new "migrations" stuffs (or a "--force" argument) would most probably have sufficed to prevent improper usage of these sql* commands, while letting django users getting the info they need to move forward, wouldn't it ?
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAJxq84_Ww_ZcuhEx8MmfcxwY%3DGpMzuPGh1maGxBDJFCikUO5MA%40mail.gmail.com.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h92CcblbYfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAFwN1upDReQpmz%2BVDaHy_SVa8Q_KtEikO-YTyz7RyDcHJAVD%3DQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CA%2BXNUS2qpByi%3D0n%3D35Hn-HhXg0xAJxY72EeiBrA4P1DEpjS7rQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c33d5b7f-9f05-4a04-b27a-7580ec72ca1d%40googlegroups.com.
As far as I'm aware, we have some code paths which still work in 1.9 which generate tables directly from the models. We use this when running Django's own test suite, and it is also used now by djangobench. I haven't looked into exactly how to turn this into logged SQL rather than run SQL but it should be possible.
I think we should document such a tool as a debugging tool rather than a development tool, but it would be useful nonetheless. Something like `sqlmigrate --from-clean` might be appropriate.
Marc
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/D3FF8860-764D-48EB-AAEE-8CE64B9ABED5%40polytechnique.org.
--
You received this message because you are subscribed to a topic in the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/django-developers/h92CcblbYfk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/CAMwjO1F8VO04xEG9-PEP7SojvG%2BZmtGZHbhpV12f%3DFEZKEBJ2A%40mail.gmail.com.
As far as I'm aware, we have some code paths which still work in 1.9 which generate tables directly from the models. We use this when running Django's own test suite, and it is also used now by djangobench. I haven't looked into exactly how to turn this into logged SQL rather than run SQL but it should be possible.
>
> An alternative would be to ignore migrations files, regenerate a fresh
> set of migrations, and dump the corresponding SQL.
I think this approach would be much preferable to using the totally
separate legacy code path. Presented as a tool for debugging migrations
issues, and with the appropriate documentation notes about RunSQL etc, I
think it would be a useful addition.
What is the new way to dump the sql schema of currently installed django appz ? It'd maybe be worth that I provide a doc patch to inform users about it.
If there is none, is there an agreement to restore at least sqlall and sqlclear ?No, there isn't :-)
They were dropped as part of the removal of the old code that supported syncing apps without migrations.
By the way, I suspect this could be implemented as a third-party app if there is opposition to including it in Django itself.
--
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-develop...@googlegroups.com.
To post to this group, send email to django-d...@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/ac575d9c-eeb4-473b-a0ca-fcc73051b903%40googlegroups.com.
OK, so I've just gone ahead and done the initial work on this: https://github.com/django/django/pull/4729
Marcin, what are you hoping to accomplish with your latest mail? As Aymeric said in another thread, repeated complaining is not going to help.
There's already an accepted ticket for this feature. If you want to be productive and helpful, pick up Andrew's patch and try to complete it. Alternatively, if the business needs justify it, you could offer to pay someone to implement it if that suits you better. Tim
No, it's not as simple as reverting the removal commit [0]. All the legacy schema generation methods are removed too [1].
We don't want to add them back
but rather use the SQL generation from the migrations system (SchemaEditor classes). Please read this thread closely and look at Andrew's pull request [2].
On Tuesday, June 21, 2016 at 4:00:51 PM UTC+2, Tim Graham wrote:No, it's not as simple as reverting the removal commit [0]. All the legacy schema generation methods are removed too [1].We don't want to add them backI know.but rather use the SQL generation from the migrations system (SchemaEditor classes). Please read this thread closely and look at Andrew's pull request [2].It is complicated for such simple job (dumping model schema to sql) but I'll give a try, just later.
Somebody wrote eariler that `sql*` commands can be written as an external app/package. They can't. Django internals must be fixed before this, or new app must provide complete solution including sql generator like SE (but this is a second nonsense, because SE is strongly coupled with db backends).
You can write the "sqlall" you want as a shell script -- remove any existing
migrations, use "makemigrations" to create an initial migratgion,
I repeat Aymeric's advice that spreading your frustrations over this mailing
list is counter-productive.
So add another step in the end to remove the temporary migrations folder
created just in order to enable sqlmigrate. If you're a real purist, add yet
another one to make sure you don't have a django_migrations table left over.
Really, this is django-users turf.
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.
> 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?
- 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?