Not sure about this but wouldn't "RunPython" actually keep you from getting an proven accurate result ? Even if we could imagine running the migration in a transaction and capturing the SQL that would be run, it would be dependent on the current data in the DB among other thing (could even be dependant on the meteo, or random variables or anything)...
And given that you can (as the doc says) use the scheme editor inside a RunPython migration, who knows what the proper SQL would be ? (again, I may be missing a point there) -- Joachim Jablon Le lundi 30 mars 2015 06:00:10 UTC+2, Andrew Godwin a écrit : > > I must also point out that the sqlmigrate command will still get you SQL > from migrations, though it sadly lacks the ability to take a range of > migrations, optimise them down, and output the SQL for _that_ - that's > probably the best thing for us to aim towards, and will almost entirely > recreate the functionality of sqlall without actually being wrong (sqlall > doesn't understand things like data migrations or custom SQL sections of > migrations, and so will sadly be wrong in if you have anything like a > moderately complex migration set). > > The plus side is that it would be possible to do this sort of thing as a > third-party command/backport if we wanted to have it usable on 1.8 and even > 1.7 (the 1.8 feature set is frozen now, or I'd suggest quickly squeezing it > in). > > Andrew > > On Sun, Mar 29, 2015 at 4:57 PM, Russell Keith-Magee < > rus...@keith-magee.com <javascript:>> wrote: > >> >> On Mon, Mar 30, 2015 at 1:36 AM, Pkl <chambon...@gmail.com <javascript:>> >> 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-develop...@googlegroups.com <javascript:>. >> To post to this group, send email to django-d...@googlegroups.com >> <javascript:>. >> 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 >> >> <https://groups.google.com/d/msgid/django-developers/CAJxq84_Ww_ZcuhEx8MmfcxwY%3DGpMzuPGh1maGxBDJFCikUO5MA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/c33d5b7f-9f05-4a04-b27a-7580ec72ca1d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
