Opened 13 years ago

Closed 8 years ago

#1002 closed enhancement (wontfix)

Add an option model name arg to [modelmodule] commands

Reported by: nirvdrum Owned by: nobody
Component: Core (Management commands) Version:
Severity: normal Keywords:
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


A few of us were batting this idea around in the IRC channel just recently. The idea came up to enhance "install", although "sqlclear" and "sqldump" were mentioned shortly thereafter.

The basic idea is that if I were to have a project named "project" and a model named "Blah" in that project, that I could execute: install project Blah

and django would execute the SQL necessary to install Blah and only that SQL. The use case trying to be addressed here is the addition of a new model. The "install" command currently fails because it attempts to install existing models and bails out. The usual recourse is to use "sqlall", but with a lot of models, finding all the correct 'auth_permissions' insert statements and what not can be a tedious and error-prone process. Given that the model being added is precisely only an addition, it should not be problematic to add this model in isolation. The extended syntax would allow this.

The same sort of rationale follows for other such commands.

Change History (9)

comment:1 Changed 13 years ago by James Bennett

Yeah, this sounded like a cool idea; if you just add a model to an app, it'd be really handy to be able to do ' install <appname> <modelname>' and just add the needed tables and columns for that model.

comment:2 Changed 13 years ago by anonymous

Type: defectenhancement

comment:3 Changed 13 years ago by nirvdrum

The syncdb command seems to take care of installing new models just fine now. There's still a gap with the other commands though.

comment:4 Changed 12 years ago by Chris Beaven

Triage Stage: UnreviewedDesign decision needed

Is this still a valid and important enough enhancement to bother about?

comment:5 Changed 12 years ago by nirvdrum@…

I'll take a look at this as soon as I can get a chance. I recall when I opened it that it was quite an annoying issue, but the DB commands have changed considerably since then. Moreover, I haven't started any new projects recently that would trigger the initial problem.

comment:6 Changed 12 years ago by Malcolm Tredinnick

Triage Stage: Design decision neededAccepted

Seems reasonable to add this for the sql* commands to Not high priority, but a good patch with a get some consideration.

comment:7 Changed 8 years ago by Adam Vandenberg

Reviewing the management commands in trunk (as of 1.3-alpha-1+), most all commands that can usefully take an appname now do. One exception is syncdb, which always creates missing tables for all apps.

So it looks like either this ticket should be resolved fixed, or be rewritten (or a new one one opened) if it would be useful for syncdb to take appnames as well to limit creation of tables in some cases.

comment:8 Changed 8 years ago by nirvdrum

I haven't used django in over 3 years now, so I can't intelligently comment on the state of the issue. adamv, please feel free to use your best judgment as to the appropriate triage state.

comment:9 Changed 8 years ago by Adam Vandenberg

Resolution: wontfix
Status: newclosed

Given the age of the ticket, the opener's lack of Django use, and the fact that most management commands that should take an appname now do, I'm going to take the liberty of closing this. Any new related requests should come through in new bugs.

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