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)
Change History (7)
comment:1 by , 14 years ago
| Component: | Uncategorized → Database layer (models, ORM) |
|---|---|
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → 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.
follow-up: 5 comment:3 by , 14 years ago
| Owner: | changed from to |
|---|---|
| Status: | assigned → 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 by , 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.
comment:5 by , 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 , 14 years ago
| Resolution: | → duplicate |
|---|---|
| Status: | new → 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.
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.