pre_syncdb signal to signal before creating tables for models

[yrashk@…]

The reason for having pre_syncdb is handling special situations like creating custom datatypes. The patch attached is very straightforward.

P.S. There is also #4528, but it's been unattended for *quite* a while.

[yrashk@…]

Patch

[James Bennett]

Do not add feature requests to the 1.1 milestone; only absolutely critical bugs should use it at this point; new features will be up for discussion once 1.1 is out the door and 1.2 is being planned.

[anonymous]

Any ETA for 1.2 discussions?

[Chris Beaven]

Patch by Silver_Ghost from #4528

[luizvital]

I have a simple use case for this:

I'm using GeoDjango and I need to INSERT custom projections to the spatial_ref_sys postgis table before any geometry field is created, because they will use the custom SRID.

This signal would be handy, specially when creating test databases.

[v.z.afzal@…]

Will this be integrated into the next Major release?

[v.z.afzal@…]

Note: If you want to apply this patch on Windows, you may need to resave the patch file in MS-DOS compatible mode.

• Open with wordpad
• Select File->Save As
• Give it a name and select the format as: Text Document - MS-DOS format

It should work after making this change

[v.z.afzal@…]

Note: If you want to apply this patch on Windows, you may need to resave the patch file in MS-DOS compatible mode.

• Open with wordpad
• Select File->Save As
• Give it a name and select the format as: Text Document - MS-DOS format

It should work after making this change

[Aymeric Augustin]

While I'm violently against signals in general, this one doesn't look too dangerous.

[stvsmth]

I see that this has a patch, tests and documentation and that it was recently accepted.

It does seem to have an old version attribute (1.1.beta).

Is there anything I can do to assist with this ticket? We us a similar custom patch and I would like to get out of the business of patching Django.

[Anssi Kääriäinen]

I think we don't want to send pre_syncdb from flush. I know post_syncdb is sent from flush, but that seems wrong, and it makes post_syncdb harder than necessary to use for schema changes. I am not even sure what one could do in pre_syncdb signal sent from flush. Creating data doesn't work, it is going to be flushed anyway, doing schema changes in pre_syncdb seems wrong, too. Maybe creating data for unmanaged models, but then those aren't ever flushed...

Could we at least add a kwarg "flush=True/False" to the signal, even if it is a bit silly to get a post_syncdb signal from flush?

I would prefer to add post_flush signal and stop sending post_syncdb from flush, but doing that is a direct break of the backwards compatibility rules... Ideas how to do that in backwards-compat way?

Otherwise the patch looks sane (patch not reviewed, just skimmed...). I am referring to: ​https://github.com/dstufft/django/compare/pre-syncdb-signal

[Donald Stufft]

It's sent there to be consistent with post_syncdb.

I would however be agreeable to not doing pre_syncdb there. As far as post_syncdb goes that's another issue that you should probably open up a ticket for so a new signal can be added and flush triggering post_syncdb can be deprecated.

[Anssi Kääriäinen]

I think it is a good idea to not send pre_syncdb from flush. I just don't see any use for that.

In addition, in separate ticket lets add a "flush" argument to post_syncdb so that one can distinguish between flush and syncdb in the signal. This is somewhat ugly, but I don't feel like tackling the backwards compatibility problems. Anyways, this is another ticket's problem.

[Donald Stufft <donald@…>]

In 3de1288042f2dc1cb8a2b36ae0fc4d9e0beb6494:

Fixed #11398 - Added a pre_syncdb signal

[Donald Stufft <donald@…>]

In 8133ee6cb4c3e9fee613ee772197dc77cdc78cd1:

Merge pull request #1200 from dstufft/pre-syncdb-signal

Fixed #11398 - Added a pre_syncdb signal