customize table name prefixes

[aaronsw]

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

I positively vote for this as well

[Jacob]

There is -- the db_table option; see ​http://www.djangoproject.com/documentation/model_api/#meta-options

[aaronsw]

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).

[Adrian Holovaty]

db_table is our solution for this.

[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?

[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.

[anonymous]

I think the benefit of having a prefix variable (in settings.py) 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?

[Russell Keith-Magee]

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

[anotheruser]

The advantage is clear:

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

Please reconsider

[Karen Tracey]

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.

[anonymous]

I support this feature request.

[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 ...