Opened 16 years ago
Closed 14 years ago
#9349 closed (wontfix)
Support for fixed Char database field
Reported by: | aiev | Owned by: | nobody |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | dev |
Severity: | Keywords: | char, varchar, fixedcharfield, field | |
Cc: | efloehr | Triage Stage: | Unreviewed |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I know that in most situations we have to use an varchar column, but not always!
CharField intuitively mean an char column.
The semantics of my database is wrong when I need to create a column of type char unless I change it directly in the database, but its not elegant.
An FixedCharField (or something else) could resolve it. :/
This is a small detail, sorry if this has no importance
Regards
Change History (3)
comment:1 by , 16 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Cc: | added |
---|---|
Keywords: | fixedcharfield field added |
Resolution: | wontfix |
Status: | closed → reopened |
Summary: | CharField create a varchar column → Support for fixed Char database field |
I would like this to be revisited, if possible, as I have seen in a number of cases where folks have asked for this functionality. I think that the "very minimal" cases where this is needed are not as small as one might first think. It is certainly not trivially small (it's appeared a couple of times on Stack Overflow, for example). The benefits of char fields are many, and as a first-order field type in all major databases (Postgres, MySQL, Oracle, etc.), the question should be "Why SHOULDN'T Django support fixed length character fields?"
Fixed char fields are useful in a number of domains, including character-based flags (in my domain, quality and measurement flags are often expressed as single characters). Varchar's in those cases result in non-trivial disk usage and performance impacts versus char fields. Besides the obvious ones, Django automagically creates a "like" index in Postgres for all varchar fields. In my particular application, changing from Django-autogenerated varchar fields to char fields dropped the size of the database from 550GB to 300GB. There are many cases when there really is fixed-length character data that needs stored.
Should you choose to close this issue again, and require folks to have to create their own field types for first-order database field types, I leave for those searching for fixed-length character fields in Django code a hacky work-around:
class FixedCharField(models.Field): def __init__(self, max_length, *args, **kwargs): self.max_length = max_length super(FixedCharField, self).__init__(max_length=max_length, *args, **kwargs) def db_type(self): return 'char(%s)' % self.max_length
Just use FixedCharField
where you are currently using models.CharField
and you should be good to go. The max_length parameter is used to specify the length of the char field.
comment:3 by , 14 years ago
Resolution: | → wontfix |
---|---|
Status: | reopened → closed |
Please don't reopen tickets that have been wontfixed. The procedure we request is that you go to django-dev if you think there's a reason for a reconsideration.
If you really need a
char
type at the database level, then you can write a custom model field that does that (it's documented how to write custom fields). This isn't needed in Django core, however, since the number of cases where you really need a fixed-length field right-padded with spaces is very minimal. Thevarchar
type can handle all those cases (possible, again, with a custom model field if you really want the right-padding).