Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#9910 closed (wontfix)

Allow to change db_table for django contrib apps

Reported by: zlw Owned by: nobody
Component: Contrib apps Version: 1.0
Severity: Keywords: db_table, table name
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


I think that Django should allow to change table name for django apps (auth, contenttype etc.). It's not hard to implement, but it can help some people (including me). I've already changed some files (django/contrib/auth/ and added new one ( in project folder). It woks now, but i don't want to change it all of the time when new Django release will come. My changes -

Attachments (1) (553 bytes) - added by zlw 10 years ago.
change table names for contrib apps

Download all attachments as: .zip

Change History (5)

Changed 10 years ago by zlw

Attachment: added

change table names for contrib apps

comment:1 Changed 10 years ago by Russell Keith-Magee

What is the use case for this change? There is a really good reason for apps to be able to specify (and enforce) the name of their own database tables, but I can't think of an obvious reason why end-users should be able to arbitrarily change these settings. Unless you can provide a compelling use case, I'm inclined to mark this 'wontfix'.

comment:2 Changed 10 years ago by zlw

Why? What if someone wants to create 2/3 or more django projects in ONE database?

comment:3 Changed 10 years ago by Russell Keith-Magee

Resolution: wontfix
Status: newclosed

First off, I'd question the wisdom of anyone that wants to put multiple projects into a single database. However, even if I did accept the use case, allowing piecemeal renaming of individual tables wouldn't be the solution. A better approach would be something like #6148, which provides for consistent schema namespacing. This way, you make one project level setting, and all tables in the project inherit a common namespace.

comment:4 in reply to:  3 Changed 10 years ago by James Bennett

Replying to russellm:

Well, as for multiple "projects" in one DB, that's a perfectly fine use case so long as you're doing it to let them share a single data source (e.g., multiple sites sharing a user database), and in fact is one of the big selling points.

Putting multiple things which shouldn't share data into the same logical DB, though, is kinda sketchy (since it opens up potential for fun/nasty bugs), though things like Postgres schemas go a long way to making that easy (and do away with the problem mentioned in this ticket).

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