This makes me wonder if you're planing to introduce a `SOUTH_TEST_MIGRATE` setting analog when moving migration handling to core.
I think most people with a huge south migration history will set this setting to `False` to speedup testsuite execution and thus they couldn't be used for database setup. Maybe people should just lean toward rebasing their migrations instead? Le lundi 20 mai 2013 03:20:32 UTC-4, Andrew Godwin a écrit : > > 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 <[email protected]<javascript:> > > 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 <[email protected]<javascript:>> >> 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" <[email protected] <javascript:>> >> 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] <javascript:>. >>> To post to this group, send email to >>> [email protected]<javascript:> >>> . >>> 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] <javascript:>. >> To post to this group, send email to >> [email protected]<javascript:> >> . >> 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 [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.
