Opened 7 years ago

Closed 4 years ago

Last modified 4 years ago

#11398 closed New feature (fixed)

pre_syncdb signal to signal before creating tables for models

Reported by: yrashk@… Owned by: nobody
Component: Core (Management commands) Version:
Severity: Normal Keywords:
Cc: luiz.vital@…, stvsmth, donald@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

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.

Attachments (2)

pre_syncdb.diff (2.8 KB) - added by yrashk@… 7 years ago.
Patch
pre_syncdb_updated.patch (8.5 KB) - added by Chris Beaven 5 years ago.
Patch by Silver_Ghost from #4528

Download all attachments as: .zip

Change History (25)

Changed 7 years ago by yrashk@…

Attachment: pre_syncdb.diff added

Patch

comment:1 Changed 7 years ago by James Bennett

milestone: 1.1

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.

comment:2 Changed 7 years ago by anonymous

Any ETA for 1.2 discussions?

comment:3 Changed 7 years ago by yrashk@…

Has patch: set

comment:4 Changed 7 years ago by yrashk@…

milestone: 1.2

comment:5 Changed 7 years ago by Alex Gaynor

Triage Stage: UnreviewedDesign decision needed

comment:6 Changed 7 years ago by Russell Keith-Magee

milestone: 1.2

comment:7 Changed 6 years ago by Julien Phalip

Severity: Normal
Type: New feature

Changed 5 years ago by Chris Beaven

Attachment: pre_syncdb_updated.patch added

Patch by Silver_Ghost from #4528

comment:8 Changed 5 years ago by luizvital

Cc: luiz.vital@… added
Easy pickings: unset
UI/UX: unset

comment:9 Changed 5 years ago by luizvital

Cc: luiz.vital@… removed

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.

comment:10 Changed 5 years ago by luizvital

Cc: luiz.vital@… added

comment:11 Changed 4 years ago by v.z.afzal@…

Will this be integrated into the next Major release?

comment:12 Changed 4 years ago by 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

comment:13 Changed 4 years ago by 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

comment:14 Changed 4 years ago by Aymeric Augustin

Component: Core (Other)Core (Management commands)

comment:15 Changed 4 years ago by Aymeric Augustin

Triage Stage: Design decision neededAccepted

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

comment:16 Changed 4 years ago by 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.

comment:17 Changed 4 years ago by stvsmth

Cc: stvsmth added
Version: 1.1-beta

comment:18 Changed 4 years ago by Donald Stufft

Cc: donald@… added

comment:19 Changed 4 years ago by 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

comment:20 Changed 4 years ago by 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.

comment:21 Changed 4 years ago by 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.

comment:22 Changed 4 years ago by Donald Stufft <donald@…>

Resolution: fixed
Status: newclosed

In 3de1288042f2dc1cb8a2b36ae0fc4d9e0beb6494:

Fixed #11398 - Added a pre_syncdb signal

comment:23 Changed 4 years ago by Donald Stufft <donald@…>

In 8133ee6cb4c3e9fee613ee772197dc77cdc78cd1:

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

Fixed #11398 - Added a pre_syncdb signal

Note: See TracTickets for help on using tickets.
Back to Top