I can specifiy some use cases.
1. Using Django as a part of bigger stack, where databases are maintained by external tool and no schema nor data modifications should be applied automatically.
2. Avoiding limitations/forcings of builitin migration system and Django ORM.
By using external database migration tool developers have flexibility and possibility to "do things right" (from db perspective).
Models are used as an read/write interface with a subset of fields.
Anf it was working good up to 1.7, and may work good with migrations turned off.
Wontfix, because does not fit design concepts of migrations. Without migrations everything is OK and works as expeced. In that case migrations are not feature but a real limitation.
And last, but not real use case (just design concept):
4. Improper migrations design
Django migrations are apps-related, same as South was. This is a not the best possible design.
There is, for example, possibility to generate migrations within python eggs (even in Django itself).
Migrations should be project-wide and splitted by database.
Developer should have possibility to change database schema as he need without forcing limitations of model-based migration system.
Not every table is mapped to model.
Kind Regards,
Marcin
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAB2m7CzKoSezwPMgQk3MZe9R-1JcmF6wA6n756tS5UBXOPR12g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment