On 26 heinä, 19:35, Andrei Antoukh <[email protected]> wrote: > Having the hooks as a method or function, I find it much more interesting > than having them in files. Above that allows logic in these methods, which > with flat files is not possible.
I also like raw SQL in Python hooks better. An example why this is preferred is that we will likely have settings configurable db_schema one day in the future. How to use the correct schema in raw SQL files when you don't control the db_schema? This could happen for example in 3rd party apps. While I am likely making this feature request more complex than it needs to be, I do think the interaction with migrations is an interesting aspect. For normal model definition changes the migrations framework spots the changes, and you get the migrations for free. Thus, you need to define the changes in just one place. For raw SQL it is impossible to automatically create migrations based on changes in the SQL. Maybe the answer to this is that you have to define the migrations separately, and the current state separately. Unfortunately this could lead to situations where you test on different schema than what your production setup will be after migrations. Thus, it would be nice to define the changes just once to ensure you can't have state errors between production and testing. And, as you can't do the "define just once" in the raw SQL hooks, it must be the migrations which contain the just once setup. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
