I run migrations in test. How else will you know your db reflects reality :/
On May 20, 2013, at 10:58 AM, charettes <[email protected]> wrote: > 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]> 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]> 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]> 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. >>> >>> >>> ----------------- >>> 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. > > -- 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.
