I can try to implement approach with pre_syncdb signal tomorrow. I think that is quite enough solution before deeper diggling into new migrations framework.
Karol 18 maj 2013 19:03, "Anssi Kääriäinen" <[email protected]> napisał(a): > On 16 touko, 11:20, Danilo Bargen <[email protected]> wrote: > > As a sidenote, there was a discussion about this on this mailing list a > few > > months ago: > > > > https://groups.google.com/forum/#!searchin/django-developers/16550/dj... > > I think a pre_sync signal is best approach. The signal should be > called either just after connecting to the (test) DB in syncdb > command, or maybe just after existing tables have been introspected so > that you know what tables are already there. Latter might be better as > syncdb can be ran multiple times, and you only need to CREATE > EXTENSION on initial sync. OTOH if you add one more model with > JSONField it seems you would need to run another CREATE EXTENSION, or > to investigate if some existing model has already ran CREATE > EXTENSION. So, defensive coding (that is, CREATE EXTENSION IF NOT > EXISTS) would be needed. > > Another problem is that post_syncdb is called from flush command, too. > This seems wrong. Could we just add post_flush signal and send that > instead? Another option is to add a "for_flush" kwarg to the signal > parameters, but it feels just so wrong to have post_syncdb signal with > an argument that tells syncdb didn't happen after all. The reason for > post_syncdb from flush is creation of ContentTypes and Permissions > after truncation of those tables. > > While the pre_syncdb signal approach has many shortcomings (how to > include the output in sqlall?), I think it is enough to solve this > problem for now. You can run CREATE EXTENSION IF NOT EXISTS and that > seems already a big step forward. Also, distinguishing post_flush from > post_syncdb seems like a good idea, but should be done in separate > ticket. > > Later on migrations framework could offer a much better solution to > this. But pre_syncdb signal seems small enough to include already in > 1.6. Maybe this could be done in the sprints? > > - Anssi > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
