On 23 touko, 06:53, Donald Stufft wrote:
> So I just submitted a PR for the pre_syncdb
> signal:https://github.com/django/django/pull/1200
>
> After I get an eye or two on it, assuming no one has any issues with it I'll
> merge it.
Minor error in docs spotted, otherwise looks
On May 21, 2013, at 12:11 PM, peter wrote:
> +1 on pre_syncdb
>
> On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
> On Tuesday 21 May 2013, Donald Stufft wrote:
> > I run migrations in test. How else will you know your db reflects reality
> > :/
> >
>
+1 on pre_syncdb
On Tuesday, May 21, 2013 8:29:49 AM UTC-7, Shai Berger wrote:
>
> On Tuesday 21 May 2013, Donald Stufft wrote:
> > I run migrations in test. How else will you know your db reflects
> reality
> > :/
> >
>
> When you have a few hundred migrations, that's something you're
On Tuesday 21 May 2013, Donald Stufft wrote:
> I run migrations in test. How else will you know your db reflects reality
> :/
>
When you have a few hundred migrations, that's something you're willing to do
in your CI server, but not on your development machine.
Shai.
--
You received this
I run migrations in test. How else will you know your db reflects reality :/
On May 20, 2013, at 10:58 AM, charettes 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
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
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
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 wrote:
> I can
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" napisał(a):
> On 16 touko, 11:20, Danilo Bargen
On 16 touko, 11:20, Danilo Bargen 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
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/django-developers/xN0aMzrmA1Y/KsrsEf7XOA8J
--
You received this message because you are subscribed to the Google Groups
"Django
On May 15, 2013, at 9:01 PM, Jacob Kaplan-Moss wrote:
> Hi folks --
>
> Does anyone have some clever thoughts on how to solve #16650?
>
> https://code.djangoproject.com/ticket/16550#comment:7 is a good
> summary of the problem: if you're using extensions, you need a way to
Hi folks --
Does anyone have some clever thoughts on how to solve #16650?
https://code.djangoproject.com/ticket/16550#comment:7 is a good
summary of the problem: if you're using extensions, you need a way to
run some custom SQL in tests after the DB gets created by the test
harness but before
13 matches
Mail list logo