Opened 6 years ago

Closed 13 months 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 6 years ago.
Change the order of syncb actions

Download all attachments as: .zip

Change History (13)

Changed 6 years ago by jbergstroem

Change the order of syncb actions

comment:1 Changed 6 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 6 years ago by toxik

  • Triage Stage changed from Unreviewed to Ready for checkin

comment:3 follow-up: Changed 6 years ago by ubernostrum

  • Triage Stage changed from Ready for checkin to Design 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 ; follow-up: Changed 6 years ago by 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.

But my apologies as I apparently misunderstood the workflow.

comment:5 in reply to: ↑ 4 Changed 6 years ago by russellm

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 4 years ago by SmileyChris

  • Severity set to Normal
  • Type set to New feature

comment:7 Changed 3 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:8 Changed 3 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:9 Changed 2 years ago by aaugustin

  • Component changed from Core (Other) to Core (Management commands)

comment:10 Changed 2 years ago by aaugustin

  • Triage Stage changed from Design decision needed to Accepted

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

comment:11 Changed 23 months ago by timo

  • Patch needs improvement set

comment:12 Changed 13 months ago by aaugustin

  • Resolution set to fixed
  • Status changed from new to closed

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