Opened 18 years ago

Closed 16 months ago

#891 closed New feature (wontfix)

customize table name prefixes

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

Description (last modified by benmath247)

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

Change History (15)

comment:1 by Jacob, 18 years ago

Resolution: invalid
Status: newclosed

comment:2 by aaronsw, 18 years ago

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 by Adrian Holovaty, 18 years ago

Resolution: invalid
Status: reopenedclosed

db_table is our solution for this.

comment:4 by Home, 18 years ago

Type: enhancementdefect

comment:5 by selik, 15 years ago

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 by Russell Keith-Magee, 15 years ago

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 by anonymous, 15 years ago

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?

comment:8 by Russell Keith-Magee, 15 years ago

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

comment:9 by anotheruser, 15 years ago

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

in reply to:  9 comment:10 by Karen Tracey, 15 years ago

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 by anonymous, 11 years ago

Easy pickings: unset
UI/UX: unset

I support this feature request.

comment:12 by mcd-php, 8 years ago

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

comment:13 by benmath247, 16 months ago

Description: modified (diff)
Needs documentation: set
Needs tests: set
Patch needs improvement: set
Resolution: invalid
Status: closednew

comment:14 by benmath247, 16 months ago

I think that this ticket feature should be added. My team needs to be able to edit the prefixes as well. One line of settings config is much better than controlling metadata on multiple tables individually.

comment:15 by Tim Graham, 16 months ago

Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset
Resolution: wontfix
Severity: normalNormal
Status: newclosed
Triage Stage: Ready for checkinUnreviewed
Type: defectNew feature

As described in comment 10, it's inappropriate to reopen this ticket without a consensus on the DevelopersMailingList. Closing per TicketClosingReasons/DontReopenTickets.

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