Opened 16 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 History (13)
by , 16 years ago
| Attachment: | change_syncdb_order.patch added |
|---|
comment:1 by , 16 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 , 16 years ago
| Triage Stage: | Unreviewed → Ready for checkin |
|---|
follow-up: 4 comment:3 by , 16 years ago
| Triage Stage: | Ready for checkin → 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.
follow-up: 5 comment:4 by , 16 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.
comment:5 by , 16 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 , 14 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:9 by , 12 years ago
| Component: | Core (Other) → Core (Management commands) |
|---|
comment:10 by , 12 years ago
| Triage Stage: | Design decision needed → Accepted |
|---|
The discussion on django-developers was in favor of improving the situation.
comment:11 by , 11 years ago
| Patch needs improvement: | set |
|---|
comment:12 by , 10 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → 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.
Change the order of syncb actions