Of course, the long-term solution for this is probably migrations. The post_syncdb signal already causes me problems - as there's no good definition for it with migrations around (you basically have to send it right at the end for every model you think you touched).
However, the patch Donald linked would be a lot easier to emulate, so I'm not that against it. Andrew On Sat, May 18, 2013 at 7:15 PM, Donald Stufft <don...@stufft.io> wrote: > There's already a patch on the ticket tracker for a pre_syncdb signal, and > yesterday I started updating it and modifying it a bit as I needed this > signal. > > https://github.com/dstufft/django/compare/pre-syncdb-signal > > On May 18, 2013, at 1:06 PM, Karol Sikora <elektrr...@gmail.com> wrote: > > 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" <anssi.kaariai...@thl.fi> > napisał(a): > >> On 16 touko, 11:20, Danilo Bargen <gez...@gmail.com> 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 django-developers+unsubscr...@googlegroups.com. >> To post to this group, send email to django-developers@googlegroups.com. >> 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 django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at http://groups.google.com/group/django-developers?hl=en > . > For more options, visit https://groups.google.com/groups/opt_out. > > > > > > ----------------- > Donald Stufft > PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 > DCFA > > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
