Code

Opened 4 years ago

Closed 4 years ago

#13176 closed (wontfix)

Provide finer control over table name conventions

Reported by: ejm Owned by: nobody
Component: Database layer (models, ORM) Version: 1.1
Severity: Keywords: database, tables
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

This is a suggestion about database table names and the way they are generated or specified. I think it would be useful if there was finer control over this.

The current default behavior (<app_name>_<model_name>) is good, but it would be useful if we could, for example:

  • specify an optional root "label", so that tables are named <root_label>_<app_name>_<model_name>
  • specify a different label for the <app_name> part (e.g. a generic 'db_table_prefix' setting that is somehow set app-wide, and which defaults to the app name)
  • specify whether to pluralize the <model_name> (possibly using the model's 'verbose_name_plural' property, or a new property e.g. 'model_name_plural')

There are probably more properties that could be added to control different aspects of name generation.

Also, if such mechanisms were provided, then possibly some of the django.contrib packages (e.g. sites, sessions, contenttypes) could use them to provide better names for their tables, rather than hard-coded 'django_sites', etc.

The reasons to be flexible and provide finer control over table naming conventions:

  • To allow Django to work alongside another platform, under a common naming scheme
  • To make the database schema more understandable to human viewers (i.e. code readability considerations, maintainability, future-proofing)
  • To keep the database conceptually separate from Django - to not have 'django_' prefixed tables or magical, "internal-looking" tables, like some other frameworks (Django is already pretty good about this and I think it fits with what I understand of the project philosophy)

Attachments (0)

Change History (2)

comment:1 Changed 4 years ago by anonymous

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

comment:2 Changed 4 years ago by russellm

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

I'm going to mark this wontfix. If you are adopting a framework, at some point you have to accept that a framework has some conventions, especially over something as fundamental as table naming.

The idea that is being proposed would add complexity to the code, but ultimately would only improve the life of a very small number of db-admins that don't like their naming schemes being messed up by a framework.

I don't pay the 'more understandable' argument. Reliable and consistent naming of internal tables is a usability issue in itself - if you bring a contractor into to work on a project, it helps if that contractor automatically knows what the content types table is called. Consistent naming can run deeper than a single code base.

I also don't pay the "conceptually separate" argument. At the end of the day, tables like content_types *are* internal. While we certainly don't prohibit anyone from tweaking them, I wouldn't describe that as generally good practice.

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.