Changing the database accidentally can be avoided simply by adjusting the privileges of the database user django uses.
Flexibility in a software project always come out at the expense of simplicity. So, generally, django developers are right to avoid rarely need features in exchange for a simple, more testable code base.
It may look simple, but in the end it is not. Think about all the tests that presume you have migrations enabled, your simple change would require new tests to try to ensure it doesn't break anything and at least a thorough check.
The thing is, nobody ever requested that, it is not a popular feature request, so, it is not there and won't be there unless someone contributes with a solid patch and a solid case for this added complexity
On Tuesday, August 25, 2015 at 12:55:29 PM UTC-3, Marcin Nowak wrote:
-- Flexibility in a software project always come out at the expense of simplicity. So, generally, django developers are right to avoid rarely need features in exchange for a simple, more testable code base.
It may look simple, but in the end it is not. Think about all the tests that presume you have migrations enabled, your simple change would require new tests to try to ensure it doesn't break anything and at least a thorough check.
The thing is, nobody ever requested that, it is not a popular feature request, so, it is not there and won't be there unless someone contributes with a solid patch and a solid case for this added complexity
On Tuesday, August 25, 2015 at 12:55:29 PM UTC-3, Marcin Nowak wrote:
> Maybe there is a solution for both?
Sometimes when you have unusual requirements you have to do a little
more work to meet them. To my knowledge, out of the many hundreds of
thousands of Django users, you are the first and only one to request a
way to turn off migrations entirely.Maybe no one else talks about it. I don't believe that there are no other database-centric projects, where Django is used to map (external) database tables to objects and generate some HTML or RESTful output.It is not possible to build a framework where _everything_ is easy. We
aim for "Simple things should be easy, advanced things should be possible."
Well.. I would like to do something as hard as usual, but turn off some unnecessary stuff. Same as not including "django.contrib.admin" in INSTALLED_APPS, same as switching template engine to Jinja2, or same as removing unnecessary middleware.I just thought that skipping some function calls is simplest than creating new feature for building workarounds, and even will be shorter than time for talking about it. But I was wrong.BR,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/298493b8-8d01-435d-a2b3-cb4d2a1ab77b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment