On Mon, Mar 30, 2015 at 1:36 AM, Pkl <chambon.pas...@gmail.com> wrote:
> 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 ?* > No, there isn't :-) 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 ? > Right now, there are two (almost) completely independent implementations of SQL table generation logic: * The legacy version, used by syncdb, sqlall, et al * The new version, used by migrate. In the past, there was a good reason for sqlall to exist - you needed to be able to run syncdb and create tables. The only time you ever called "CREATE TABLE" was when a table was fresh, and after that, you never issued any command related to the table schema. It didn't hurt anyone to allow sqlall to generate "what would the CREATE TABLE be if we had clean databases", and it was at least partially useful as a migration assistant, so the sqlall functionality was available. In the era of migrations, there's still a need to do a CREATE TABLE, but the table creation logic is a lot more complex, because it's not *just* a CREATE TABLE that is needed; all the ALTER TABLE statements are needed to add/remove columns as well. It would probably be *possible* to refactor manage.py sqlall to use the new table creation logic; but the question would then be "why do you want it"? manage.py migration *should* be handling all your table creation and migration functionality, so the need to manually diff a schema shouldn't exist. If you've hit problems with "manage.py migrate" *not* identifying migrations, then that's a much bigger problem, and one that needs to be reported as a bug - because it's a huge bug. Anything you can do to narrow down the situation that led to the problems you've observed would be very helpful. Yours, Russ Magee %-) -- 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/CAJxq84_Ww_ZcuhEx8MmfcxwY%3DGpMzuPGh1maGxBDJFCikUO5MA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
