Coming back to this: I think making the pre/post sync signals usable for this seems like a good enough approach until migrations framework gives us a cleaner way for this.
The problem is easiest to see in a custom HSTORE field. There is need to issue a "create extension hstore" before any model is installed. Currently there doesn't seem to be any clear way to do this, working for testing and production databases alike. In addition there might be need for creating a GIST index for that field, after the model is created, and again my understanding is that this is hard if not impossible to do. So, what we need is a way to run pre/post-project-sync SQL and pre- post-model-sync SQL. App sync doesn't need to be handled at the moment. The pre/post signals gives us a crude way to do this, but this is still a lot better than what we have now. Clean slate would IMHO call for three signal sets: pre/post_sync, pre/ post_flush and pre/post_project_sync. For backwards compatibility reasons the pre/post_flush signals need to go together with pre/ post_sync. I think you are right that throwing the project signal in to the same mix (and later on migrate and app signals, too) is a little ugly. Go with what you feel works best. Sorry for ping-ponging this issue, this is just my design style: try a lot of things and see what works. - Anssi On 29 heinä, 17:02, Andrei Antoukh <[email protected]> wrote: > 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.
