Code

Opened 5 years ago

Closed 5 years ago

Last modified 5 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: UI/UX:

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_db_table.py (553 bytes) - added by zlw 5 years ago.
change table names for contrib apps

Download all attachments as: .zip

Change History (5)

Changed 5 years ago by zlw

change table names for contrib apps

comment:1 Changed 5 years ago by russellm

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 5 years ago by zlw

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

comment:3 follow-up: Changed 5 years ago by russellm

  • Resolution set to wontfix
  • Status changed from new to 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 in reply to: ↑ 3 Changed 5 years ago by ubernostrum

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).

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.