Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Anssi Kääriäinen]

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 good to me.

I am thinking of adding a "for_action" kwarg for post_syncdb.
Currently there is no way to distinguish between flush and syncdb.
This makes it impossible to use the signal for schema changes. I guess
the kwarg could be useful for migrations, too.

Does this sound reasonable? Would the for_action kwarg help with
South?

The pre_syncdb signal isn't sent for flush. I think this is correct,
as I can't see anything you could do in pre_syncdb signal for flush.
If there are use cases, then I think adding for_action to pre_syncdb
should be done. IMO we can do these minor changes after alpha if need
be.

 - 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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

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 
> > :/ 
> > 
> 
> 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 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.
>  
>  


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.

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[peter]

+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 willing to 
> do 
> in your CI server, but not on your development machine. 
>
> Shai. 
>

-- 
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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Shai Berger]

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 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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

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 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  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  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"  napisał(a):
> 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
> 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-develop...@googlegroups.com.
> To post to this group, send email to django-d...@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-develop...@googlegroups.com.
 To post to this group, send email to django-d...@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 

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[charettes]

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  > 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  
>> 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"  
>> napisał(a):
>>
>>> 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
>>> 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-develop...@googlegroups.com .
>>> To post to this group, send email to 
>>> django-d...@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-develop...@googlegroups.com .
>> To post to this group, send email to 
>> django-d...@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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Andrew Godwin]

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  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  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" 
> napisał(a):
>
>> 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
>> 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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

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 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  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

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Karol Sikora]

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  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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Anssi Kääriäinen]

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
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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Danilo Bargen]

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 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.

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Donald Stufft]

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
> run some custom SQL in tests after the DB gets created by the test
> harness but before syncdb runs.
> 
> The current patch and suggested solution on the ticket won't work (see
> the thread), but I think it's a legit need and I'd like to come up
> with a good solution and possibly reopen the ticket.
> 
> Jacob
> 
> -- 
> 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.
> 
> 

pre_syncdb signal? syncdb is still called in tests right?

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail

Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Jacob Kaplan-Moss]

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 syncdb runs.

The current patch and suggested solution on the ticket won't work (see
the thread), but I think it's a legit need and I'd like to come up
with a good solution and possibly reopen the ticket.

Jacob

-- 
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.