Opened 15 years ago

Closed 10 years ago

#10236 closed New feature (fixed)

Change order of actions in syncdb

Reported by: jbergstroem Owned by: nobody
Component: Core (Management commands) Version: dev
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 15 years ago.
Change the order of syncb actions

Download all attachments as: .zip

Change History (13)

by jbergstroem, 15 years ago

Attachment: change_syncdb_order.patch added

Change the order of syncb actions

comment:1 by jbergstroem, 15 years ago

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 by Ludvig Ericson, 15 years ago

Triage Stage: UnreviewedReady for checkin

comment:3 by James Bennett, 15 years ago

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.

in reply to:  3 ; comment:4 by Ludvig Ericson, 15 years ago

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.

in reply to:  4 comment:5 by Russell Keith-Magee, 15 years ago

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 by Chris Beaven, 13 years ago

Severity: Normal
Type: New feature

comment:7 by Aymeric Augustin, 12 years ago

UI/UX: unset

Change UI/UX from NULL to False.

comment:8 by Aymeric Augustin, 12 years ago

Easy pickings: unset

Change Easy pickings from NULL to False.

comment:9 by Aymeric Augustin, 11 years ago

Component: Core (Other)Core (Management commands)

comment:10 by Aymeric Augustin, 11 years ago

Triage Stage: Design decision neededAccepted

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

comment:11 by Tim Graham, 11 years ago

Patch needs improvement: set

comment:12 by Aymeric Augustin, 10 years ago

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