I'll be happy to look at whatever you come up with or review whatever changes you think need to be made in Django to solve the ticket, however, I fail to understand how Andrew's proposal isn't suitable. Maybe you could give more specific details than "migrations may be corrupted" and "they are unreliable". As far as I see, Andrew's proposal doesn't use any on-disk migrations so it doesn't require an app to have migrations.
Yes, I did remove the sql* commands because they were scheduled for removal when the migrations system was introduced. We didn't want to maintain two methods for generating schema. Your previous mail was just rehashing old complaints about the lack of this functionality. If I were in your shoes and needed this functionality, I would get involved and try to engage in a discussion to learn about the reasons for this. Then I would make a proposal for how to solve the problem and then implement it. I wouldn't complain about it, disparage the design of the Django, and expect someone else to write the code that I need. Anyway, it sounds like you're off on the right path now. You have a lot of interesting ideas about where Django could be improved but please share them in a polite and constructive fashion. Avoid pointless statements like "Sorry, but it looks like code written in big hurry" which only serve to offend the people who spend many hours contributing to Django. If you continue down that path, I guess all we can do is ignore you because we don't like to work with people who can't be polite. On Tuesday, June 21, 2016 at 4:55:13 PM UTC-4, Marcin Nowak wrote: > > > > On Tuesday, June 21, 2016 at 5:49:08 PM UTC+2, Marcin Nowak wrote: >> >> >> >> 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 back >>> >> >> I 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. >> >> > No, Tim. I will not go through the Andrew's path. It is a "dead end". > What the `sql` command should do is just simple dump model meta to desired > sql dialect. > > Migrations are designed to manage and apply model changes, so it is quite > different use case. > > `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. > > > The only way is to fix SchemaEditor by extractnig sql from create_model(), > without executing it. But it's not so easy, because SE requires to be run > as a context manager and executes deffered sqls at __exit__(). There are > other SE`s methods which depends on defferend sql execution at > `__exit__()`. Sorry, but it looks like code written in big hurry. > > If SchemaEditor will not be removed in near future, I can try to patch it > and use as a base of new `sql` command. I think there is no other > reasonable way to do that. > > 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). > > And finally I would like to remind you, that `sql*` commands were removed > by you. This was a mistake. Not the first, not the last. But when you're > asking me what I'm hoping writing such mails, just please stand in my (and > others) shoes and think a little about it. > > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/1231b31e-1f17-4bf1-a2ca-c8e364dac69d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
