[patch] Table prefix

[vitja <dummylink@…>]

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

[Adrian Holovaty]

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

[Chris Beaven]

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.

[fotinakis]

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.

[fotinakis]

Patch for table prefixing and docs

[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/models.py", 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/models.py", 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/models.py", line ?, in regressiontests.queries.models.test.API_TESTS
Failed example:

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

OperationalError: no such table: django_site

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

Item.objects.extra(tables=queries_author).select_related().order_by('name')[:1]

OperationalError: no such table: queries_author

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

File "/home/user/django-trunk/tests/regressiontests/extra_regress/models.py", 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/models.py", line ?, in modeltests.unmanaged_models.models.test.API_TESTS
Failed example:

C02.objects.filter(mm_a=a.id)

OperationalError: no such table: test_D01

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

[Russell Keith-Magee]

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.

[fotinakis]

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