#9349: Support for fixed Char database field
---------------------------------------------------+------------------------
          Reporter:  aiev                          |         Owner:  nobody     
                         
            Status:  reopened                      |     Milestone:             
                         
         Component:  Database layer (models, ORM)  |       Version:  SVN        
                         
        Resolution:                                |      Keywords:  char, 
varchar, fixedcharfield, field
             Stage:  Unreviewed                    |     Has_patch:  0          
                         
        Needs_docs:  0                             |   Needs_tests:  0          
                         
Needs_better_patch:  0                             |  
---------------------------------------------------+------------------------
Changes (by efloehr):

 * cc: efloehr (added)
  * keywords:  char, varchar => char, varchar, fixedcharfield, field
  * status:  closed => reopened
  * resolution:  wontfix =>
  * summary:  CharField create a varchar column => Support for fixed Char
              database field

Comment:

 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.

-- 
Ticket URL: <http://code.djangoproject.com/ticket/9349#comment:2>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/django-updates?hl=en.

Reply via email to