Opened 12 years ago

Closed 10 years ago

Last modified 10 years ago

#5000 closed (wontfix)

[patch] Table prefix

Reported by: vitja <dummylink@…> Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: master
Severity: Keywords: table prefix
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no


This patch allows to set prefex for django tables, using settings.DATABASE_TABLE_PREFIX variable.

Attachments (2)

table-prefix.diff (740 bytes) - added by vitja <dummylink@…> 12 years ago.
table-prefix-better.diff (2.3 KB) - added by fotinakis 10 years ago.
Patch for table prefixing and docs

Download all attachments as: .zip

Change History (8)

Changed 12 years ago by vitja <dummylink@…>

Attachment: table-prefix.diff added

comment:1 Changed 12 years ago by Adrian Holovaty

What's the use case for this? Shared hosting, where you only have one database and want to install multiple Django sites?

comment:2 Changed 12 years ago by Chris Beaven

Resolution: wontfix
Status: newclosed

Closing, since it just adds another setting and is a minority case. Feel free to convince the developers of it's merits in the Django-dev google group.

comment:3 Changed 10 years ago by fotinakis

Needs tests: set
Resolution: wontfix
Status: closedreopened

I'd like to re-open this ticket and submit a better patch against trunk; it seems very reasonable to allow a global prefix on all the table names in a Django project. It is a simple change that will allow more limited environments to host multiple Django instances, including the use case mentioned by adrian about shared hosting with only one database (or, at least, access to only one schema). The patch submitted here takes care of adding the prefix to models who's table names are manually specified in that model's Meta: db_table attribute (this must be done so that models in included apps are also prefixed).

The only case where I can see things breaking is in use of custom SQL on a model manager, where an included app's custom SQL uses a specific table name. Is there any custom SQL in the Django core or contrib that would break when specifying a prefix? Running the test suite didn't seem to reveal any.

The patch also includes updates to the documentation. Does this all look ok? Hope this helps.

Changed 10 years ago by fotinakis

Attachment: table-prefix-better.diff added

Patch for table prefixing and docs

comment:4 Changed 10 years ago by fotinakis

I take it back, :/ running the test suite DID reveal a bunch. Is there any elegant way to fix this? Or am I just beating a dead horse...

Failed to install custom SQL for initial_sql_regress.Simple model: no such table: initial_sql_regress_simple

File "/home/user/django-trunk/tests/regressiontests/queries/", line ?, in regressiontests.queries.models.test.API_TESTS
Failed example:

Item.objects.values('notenote').order_by('queries_note.note', 'id')

File "/home/user/django-trunk/tests/regressiontests/queries/", line ?, in regressiontests.queries.models.test.API_TESTS
Failed example:

[o.count for o in l]

OperationalError: no such table: queries_item_tags

File "/home/user/django-trunk/tests/regressiontests/queries/", line ?, in regressiontests.queries.models.test.API_TESTS
Failed example:

Ranking.objects.extra(tables=django_site?, order_by=['', 'rank'])

OperationalError: no such table: django_site

File "/home/user/django-trunk/tests/regressiontests/queries/", line ?, in regressiontests.queries.models.test.API_TESTS
Failed example:


OperationalError: no such table: queries_author

FAIL: Doctest: regressiontests.queries.models.test.API_TESTS

File "/home/user/django-trunk/tests/regressiontests/extra_regress/", line ?, in regressiontests.extra_regress.models.test.API_TESTS
Failed example:

Order.objects.extra(where=username=%s?, params=fred?, tables=auth_user?).order_by('created_by')

OperationalError: no such table: auth_user

File "/home/user/django-trunk/tests/modeltests/unmanaged_models/", line ?, in modeltests.unmanaged_models.models.test.API_TESTS
Failed example:


OperationalError: no such table: test_D01

It's probably evil to just parse the DATABASE_TABLE_PREFIX into those SQL statements, right?

comment:5 Changed 10 years ago by Russell Keith-Magee

Resolution: wontfix
Status: reopenedclosed

This ticket was closed by a triager after being questioned by a BDFL with a direction to ask on django-dev if you wanted to argue for the merits of the idea.

I'm afraid I still don't see the massive benefit here - it's a big complication for very little gain, for which many better solutions (schemas, separate databases) already exist.

comment:6 Changed 10 years ago by fotinakis

Agreed, it is much more complicated than it's worth. Thanks for the input.

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