On 27 heinä, 12:01, Andrew Godwin <[email protected]> wrote:
> 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.

The problem with post_syncdb is that it is fired also after db flush.
Thus you get the SQL applied after every transactional test case, and
that means you can't have DDL commands in the post sync SQL. This
should be easy enough to fix by introducing a new kwarg which tells
when the signal is sent (flush, sync, migrate).

In addition we could add post_sync without sender for whole project,
and post_sync with an App as sender when the app-loading refactor gets
in.

It seems we would also need a pre-sync signal, too.

The only downside I can see is that this way you can't show the SQL as
part of sqlall. Maybe we should just forget about this limitation, and
continue with the signals.

Once the migrations get in, we can make sure we have a nice framework
for initial SQL, and then recommend not using the sync signals at all.

So, maybe this would work:
  - add a new signal for pre sync.
  - add a new kwarg to pre/post sync which tells if the signal is
fired on flush or on sync.
  - add pre/post sync for the whole project.
  - add pre/post sync for apps once the app-loading refactor gets in.

 - 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.

Reply via email to