2012/7/27 Anssi Kääriäinen <[email protected]> > 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. >
I hate to use the signal post_syncdb for everything (project, app, model), I think it is to use a feature for more things you should. > It seems we would also need a pre-sync signal, too. > OK > > 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. > The sql that runs on the handlers of signals, is the only one who can not see part of the output of sqlall. But we can provide alternatives. See: https://gist.github.com/3198204 > > 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 Now in my spare time I am working on a prototype. I hope suggestions and improvements! I think they should make a small refactor on the order of execution of the command "syncdb". And I have doubts as to how to deal with the signals for this. Andrey. > -- > 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. > > -- Andrei Antoukh - <[email protected]> http://www.niwi.be/page/about/ http://www.kaleidos.net/A5694F/ "Linux is for people who hate Windows, BSD is for people who love UNIX" "Social Engineer -> Because there is no patch for human stupidity" -- 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.
