Code

Opened 8 years ago

Closed 5 years ago

Last modified 10 months ago

#891 closed defect (invalid)

customize table name prefixes

Reported by: aaronsw Owned by: adrian
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

Description

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.

Attachments (0)

Change History (11)

comment:1 Changed 8 years ago by jacob

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

comment:2 Changed 8 years ago by aaronsw

  • Resolution invalid deleted
  • Status changed from closed to reopened

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 8 years ago by adrian

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

db_table is our solution for this.

comment:4 Changed 8 years ago by Home

  • Type changed from enhancement to defect

comment:5 Changed 5 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 5 years ago by russellm

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

comment:8 Changed 5 years ago by russellm

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

comment:9 follow-up: Changed 5 years ago by anotheruser

  • Resolution invalid deleted
  • Status changed from closed to reopened

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

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

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 10 months ago by anonymous

  • Easy pickings unset
  • UI/UX unset

I support this feature request.

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.