Code

Opened 7 years ago

Closed 5 years ago

Last modified 5 years ago

#5000 closed (wontfix)

[patch] Table prefix

Reported by: vitja <dummylink@…> Owned by: adrian
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: UI/UX:

Description

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@…> 7 years ago.
table-prefix-better.diff (2.3 KB) - added by fotinakis 5 years ago.
Patch for table prefixing and docs

Download all attachments as: .zip

Change History (8)

Changed 7 years ago by vitja <dummylink@…>

comment:1 Changed 7 years ago by adrian

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

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 7 years ago by SmileyChris

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

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 5 years ago by fotinakis

  • Needs tests set
  • Resolution wontfix deleted
  • Status changed from closed to reopened

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 5 years ago by fotinakis

Patch for table prefixing and docs

comment:4 Changed 5 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/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?

comment:5 Changed 5 years ago by russellm

  • Resolution set to wontfix
  • Status changed from reopened to closed

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 5 years ago by fotinakis

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

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.