Opened 4 years ago

Closed 4 years ago

#15238 closed (duplicate)

global TABLE_PREFIX setting

Reported by: dgl Owned by: carljm
Component: Database layer (models, ORM) Version: master
Severity: Keywords:
Cc: Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: yes
Easy pickings: UI/UX:

Description

Followed by this discussion. There should be TABLE_PREFIX property, which will be prepended to all generated db_table options

Attachments (1)

patch.diff (1.6 KB) - added by dgl 4 years ago.
first patch

Download all attachments as: .zip

Change History (7)

comment:1 Changed 4 years ago by carljm

  • Component changed from Uncategorized to Database layer (models, ORM)
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Triage Stage changed from Unreviewed to Accepted

Nobody had anything to say in the mailing list thread, but on the face of it this seems like a pretty reasonable feature to me. There's no reason an installation of Django has to insist on claiming the entire table namespace for itself.

#13176 was similar and closed wontfix, but largely on the basis of "added complexity," and that ticket was requesting much broader flexibility, which would have required much more added complexity than just a prefix.

The TABLE_PREFIX setting should be per-database (i.e. a key in the DATABASES["db_alias"] dict), not a global setting.

Last edited 4 years ago by carljm (previous) (diff)

Changed 4 years ago by dgl

first patch

comment:2 Changed 4 years ago by dgl

  • Owner changed from nobody to anonymous
  • Status changed from new to assigned

Sorry, I added that patch before I've seen your latest comment. I'm gonna rewrite that patch with per-database support instead of the global setting.

comment:3 follow-up: Changed 4 years ago by dgl

  • Owner changed from anonymous to carljm
  • Status changed from assigned to new

I just tried to think it all through and it appears there is a problem with per-database setting.

Model metaclass has db_table property which should contain value disregarding of what database we are using. What value should it contain if we have different prefixes for different DBs?

comment:4 Changed 4 years ago by lrekucki

  • Has patch set
  • Needs tests set
  • Patch needs improvement set

Your new patch should also include tests to show that the setting works as expected.

comment:5 in reply to: ↑ 3 Changed 4 years ago by carljm

Replying to dgl:

I just tried to think it all through and it appears there is a problem with per-database setting.

Model metaclass has db_table property which should contain value disregarding of what database we are using. What value should it contain if we have different prefixes for different DBs?

Urg, that is a bit of a puzzler. I guess that means it has to be a global setting, but that feels wrong; the need for prefixed table names is a per-database need. Need to think this one over...

comment:6 Changed 4 years ago by carljm

  • Resolution set to duplicate
  • Status changed from new to closed

In my prior art search, I missed #5000, the only other ticket where this exact feature was proposed. (#388 and #891 are similar, but not the same). #5000 brings up some additional problematic cases, such as apps that come bundled with initial SQL, which will break on any project with a global table-prefix setting applied.

Closing as duplicate of #5000. I still think this is at its core a reasonable request, but I don't see how to implement it in a good way without breakage, and I'm not sure it's a high enough priority to be worth much fiddling. Further discussion should happen on the mailing list.

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