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
signature.asc
Description: Message signed with OpenPGP using GPGMail
