#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 |
Description
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/backends.py) and added new one (change_db_table.py 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 - http://pastie.org/346481
Attachments (1)
Change History (5)
by , 16 years ago
Attachment: | change_db_table.py added |
---|
comment:1 by , 16 years ago
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 by , 16 years ago
Why? What if someone wants to create 2/3 or more django projects in ONE database?
follow-up: 4 comment:3 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
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 by , 16 years ago
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).
change table names for contrib apps