Opened 12 years ago

Closed 8 years ago

Last modified 20 months ago

#891 closed defect (invalid)

customize table name prefixes

Reported by: aaronsw Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version:
Severity: normal Keywords:
Cc: Triage Stage: Ready for checkin
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently if a table is defined in a module named then the tables will be prefixed with "gork_". There should be some way to override this.

Change History (12)

comment:1 Changed 12 years ago by Jacob

Resolution: invalid
Status: newclosed

comment:2 Changed 12 years ago by aaronsw

Resolution: invalid
Status: closedreopened

The db_table option only lets you set the name for one table, it doesn't let you adjust the prefix for all of them (unless you set db_table for every table in the file).

comment:3 Changed 11 years ago by Adrian Holovaty

Resolution: invalid
Status: reopenedclosed

db_table is our solution for this.

comment:4 Changed 11 years ago by Home

Type: enhancementdefect

comment:5 Changed 8 years ago by selik

I'm new to this, so perhaps I don't understand how things work on this project. It seems like this feature would be handy. Why set the ticket to "closed:invalid" without explaining how the db_table Meta setting is a valid solution?

comment:6 Changed 8 years ago by Russell Keith-Magee

I'm not sure what explanation is required. db_table lets you set the name of the table used for any model. If you want your table to be called foo_model rather than gork_model, then you put db_table = 'foo_model' in your Meta settings. What has been rejected is the idea of a db_prefix setting that would enable you to specify db_prefix='foo_', and get foo_model generated automatically.

In this case, I completely agree with Adrian and Jacob - I don't see any benefit to having such a prefix. db_table solves the problem of naming a table something other than the default. Providing micro-configuration like a db_prefix setting introduces a bunch of complexity (How do db_table and db_prefix interact?), and requires duplicated specifications if you have multiple models (How could you specify db_prefix for an entire app?), all in order to support a fairly small set of edge cases.

By way of process - if you disagree with this decision, feel free to raise the issue and make your case on the django-developers mailing list. However, in this case, I'm fairly confident you will get the same response.

comment:7 Changed 8 years ago by anonymous

I think the benefit of having a prefix variable (in would be if you want to copy the project to another location/directory, you don't have to change your models. I would also find this useful and logical, would you consider reopening this ticket?

comment:8 Changed 8 years ago by Russell Keith-Magee

Please re-read my previous comment - in particular, the last paragraph.

comment:9 Changed 8 years ago by anotheruser

Resolution: invalid
Status: closedreopened

The advantage is clear:

One line of configuration vs. manually maintaining a meta-class for every single model class?

Please reconsider

comment:10 in reply to:  9 Changed 8 years ago by Karen Tracey

Resolution: invalid
Status: reopenedclosed

Replying to anotheruser:

Please reconsider

The way to get the decision reconsidered is to raise the issue on the django-developers mailing list. If you get consensus there that this is worthwhile, THEN it is appropriate to re-open this ticket. Continually re-opening a ticket in the tracker is not productive. Those who see such updates have mostly already made up their minds. In this case you've got 3 core developers who have indicated they do not see the usefulness of this. You absolutely need to get wider support from the community than is possible to gauge in trac before this would be implemented. That is why the process requests raising issues on django-developers rather than reopening tickets. The wider development community reads the mailing list, it does not generally follow every trac update.

comment:11 Changed 4 years ago by anonymous

Easy pickings: unset
UI/UX: unset

I support this feature request.

comment:12 Changed 20 months ago by mcd-php

I positively vote for this !

I created my project in ignorance of table naming convention, named it like verbose_marketing_name_tld.

I generate my tables (and probably will generate my code) from XML, I have lots of tables split into nested groups, and so sadly Django does not support PostgreSQL schemas (I use schemas in data collection and transformation staging database, otherwise i'd be lost in their numbers and scroll off my mouse wheel). To make things more sad, my tables have prefixes already.

So finally I end up with tables named like verbose_marketing_name_tld_etla_somelongnoun_to_otherlongnoun, and it would be really handy to bend them into at least vmnt_etla_somelongnoun_to_otherlongnoun by the single change, so Don't Repeat Yourself.

Of course, it will take time to implement in framework and I must do my task today, so I'll be forced to implement kludges and crutches, but this feels so sad ...

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