OK, so I've just gone ahead and done the initial work on this: https://github.com/django/django/pull/4729
I'd appreciate testing by people to see how well that new sql command works; it's fine for me in dev here against a simple project but there's probably some edge cases. Nevertheless, it seems to prove the idea and is also the way we can handle test database setup potentially, too. On Mon, Jun 1, 2015 at 1:41 PM, Tim Graham <timogra...@gmail.com> wrote: > As far as justification for dropping the old commands: > > 1. Andrew said earlier in the thread, "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)." > > 2. The sql* commands that were removed relied on SQL generation code in > django/db/backends/base/creation.py and has been superseded by similar > functionality in schema.py (and removed in 1.9). Django shouldn't maintain > two ways of generating SQL for models. > > We welcome your contribution if you can form a consensus on a proposal. > > > On Monday, June 1, 2015 at 4:00:14 AM UTC-4, Marcin Nowak wrote: >> >> >> On Sunday, May 31, 2015 at 1:47:32 AM UTC+2, Tim Graham wrote: >>> >>> They were dropped as part of the removal of the old code that supported >>> syncing apps without migrations. >>> >> >> But you removed a feature, not just old code. >> In v1.8 (1.7 maybe?) this feature was broken (issue #24876) and it was >> completely removed in master (issue #24481). >> This is not good. >> >> >>> >>> By the way, I suspect this could be implemented as a third-party app if >>> there is opposition to including it in Django itself. >>> >> >> I know I can reimplement it myself, but core feature should be nearest to >> core source code, because it highly depends on internals. >> This can be provided as a contrib app, for example. >> >> Why contrib.gis is supported for years? This app is used rarely. In >> contrast to gis - we generate/create SQLs every day. >> I don't know what you're doing with Django, but latests changes looks >> fearfull.. :( >> >> /BR >> 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 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 > <https://groups.google.com/d/msgid/django-developers/ac575d9c-eeb4-473b-a0ca-fcc73051b903%40googlegroups.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/CAFwN1urVVW3hOkuT2vdAbm5EVv4pVs7MEvM9ejBEejSorYCrAQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
