On 26/07/12 19:33, Anssi Kääriäinen wrote:
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.
Chiming in here on the migration front, my proposal for the next-gen
migration solution that'll potentially land in Django includes support
for just running chunks of raw SQL, so there's potential to auto-include
those in an initial migration.
However, as you quite rightly point out, detecting changes is a pain.
Still, South sends the post_syncdb signal after model creation anyway,
so there's potential here for people who are lazy and don't want to port
their SQL across to migrations to have it Just Work. (and then Just Fail
when they want to change it). It should be good enough until I get the
migration stuff in, I'd say.
Andrew
--
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.
