Opened 8 years ago

Closed 2 years ago

#10236 closed New feature (fixed)

Change order of actions in syncdb

Reported by: jbergstroem Owned by: nobody
Component: Core (Management commands) Version: master
Severity: Normal Keywords: order syncdb sql index
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no

Description

Syncdb currently executes actions in this order:

  • Create tables
  • Create m2m tables
  • (optional) Run custom sql
  • Create indexes
  • (optional) Run fixtures

This makes it hard to execute custom sql such as "remove these indexes that Django created for me but never are used". Changing the current order won't break anything since indexes are calculated from models, and if the user chooses to break their models - django can't do much about it. The optimal thing to do here is probably running indexes after fixtures has been inserted (faster inserts and index creation), but this is a larger step from the current way and needs to be thoroughly tested.

Attached patch changes order so indexes are inserted before custom sql. Sqlall output is also patched for consistency. One additional thing that _could_ be clarified is documentation regarding good practices in fixtures and custom SQL - but this is far from needed in this patch.

Attachments (1)

change_syncdb_order.patch (3.6 KB) - added by jbergstroem 8 years ago.
Change the order of syncb actions

Download all attachments as: .zip

Change History (13)

Changed 8 years ago by jbergstroem

Attachment: change_syncdb_order.patch added

Change the order of syncb actions

comment:1 Changed 8 years ago by jbergstroem

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

Forgot to mention that a discussion regarding this can be found here: http://groups.google.com/group/django-developers/browse_thread/thread/c74a9b440e2c4c2

comment:2 Changed 8 years ago by Ludvig Ericson

Triage Stage: UnreviewedReady for checkin

comment:3 Changed 8 years ago by James Bennett

Triage Stage: Ready for checkinDesign decision needed

This isn't "ready for checkin"; there's been no review of the patch whatsoever, and no feedback from the dev team on whether this change will be accepted.

comment:4 in reply to:  3 ; Changed 8 years ago by Ludvig Ericson

Replying to ubernostrum:

This isn't "ready for checkin"; there's been no review of the patch whatsoever, and no feedback from the dev team on whether this change will be accepted.

I was under the impression that the triaging was exactly for that purpose: flagging 'I reviewed this.' And I did.

But my apologies as I apparently misunderstood the workflow.

comment:5 in reply to:  4 Changed 8 years ago by Russell Keith-Magee

Replying to toxik:

Replying to ubernostrum:

This isn't "ready for checkin"; there's been no review of the patch whatsoever, and no feedback from the dev team on whether this change will be accepted.

I was under the impression that the triaging was exactly for that purpose: flagging 'I reviewed this.' And I did.

If you follow the triage notes the jump from 'Unreviewed' to 'Accepted' is only for obvious or trivial bugs. This isn't an obvious bug, and it won't be a trivial change - it has consequences for existing code. As a result, a design decision is required.

comment:6 Changed 5 years ago by Chris Beaven

Severity: Normal
Type: New feature

comment:7 Changed 5 years ago by Aymeric Augustin

UI/UX: unset

Change UI/UX from NULL to False.

comment:8 Changed 5 years ago by Aymeric Augustin

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:9 Changed 4 years ago by Aymeric Augustin

Component: Core (Other)Core (Management commands)

comment:10 Changed 4 years ago by Aymeric Augustin

Triage Stage: Design decision neededAccepted

The discussion on django-developers was in favor of improving the situation.

comment:11 Changed 3 years ago by Tim Graham

Patch needs improvement: set

comment:12 Changed 2 years ago by Aymeric Augustin

Resolution: fixed
Status: newclosed

The original use case was to "remove these indexes that Django created for me but never are used".

The new migrations framework provide excellent tools to do this, with its RunSQL operation.

It can be positioned where needed by declaring dependencies.

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