Opened 6 years ago

Closed 4 years ago

#9349 closed (wontfix)

Support for fixed Char database field

Reported by: aiev Owned by: nobody
Component: Database layer (models, ORM) Version: master
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: UI/UX:

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 Changed 6 years ago by mtredinnick

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset
  • Resolution set to wontfix
  • Status changed from new to closed

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. The varchar type can handle all those cases (possible, again, with a custom model field if you really want the right-padding).

comment:2 Changed 4 years ago by efloehr

  • Cc efloehr added
  • Keywords fixedcharfield field added
  • Resolution wontfix deleted
  • Status changed from closed to reopened
  • Summary changed from CharField create a varchar column to 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 Changed 4 years ago by mtredinnick

  • Resolution set to wontfix
  • Status changed from reopened to 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.

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