Opened 14 years ago

Closed 14 years ago

#15238 closed (duplicate)

global TABLE_PREFIX setting

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

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 Dmitry Gladkov 14 years ago.
first patch

Download all attachments as: .zip

Change History (7)

comment:1 by Carl Meyer, 14 years ago

Component: UncategorizedDatabase layer (models, ORM)
Triage Stage: UnreviewedAccepted

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 14 years ago by Carl Meyer (previous) (diff)

by Dmitry Gladkov, 14 years ago

Attachment: patch.diff added

first patch

comment:2 by Dmitry Gladkov, 14 years ago

Owner: changed from nobody to anonymous
Status: newassigned

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 by Dmitry Gladkov, 14 years ago

Owner: changed from anonymous to Carl Meyer
Status: assignednew

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 by Łukasz Rekucki, 14 years ago

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.

in reply to:  3 comment:5 by Carl Meyer, 14 years ago

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 by Carl Meyer, 14 years ago

Resolution: duplicate
Status: newclosed

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