possible bug - CharField accepts string as max_length

[Santiago L]

Hi,

I think that I have found a bug on the system check: it accepts a string as value for CharField.max_length argument.

It happens only if the string can be converted to int (e.g. max_length='16'). Otherwise shows fields.E121 error (e.g. max_length='foo').

from django.db import models

class Foo(models.Model):
    bar = models.CharField(max_length='16')


# following code raises an Exception
obj = Foo(bar='lorem ipsum')
obj.clean_fields()

Traceback:

>>> obj = Foo(bar='lorem ipsum')

>>> obj.clean_fields()

Traceback (most recent call last):

  File "<console>", line 1, in <module>

  File "/usr/local/lib/python3.4/dist-packages/django/db/models/base.py", line 1167, in clean_fields

    setattr(self, f.attname, f.clean(raw_value, self))

  File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 589, in clean

    self.run_validators(value)

  File "/usr/local/lib/python3.4/dist-packages/django/db/models/fields/__init__.py", line 541, in run_validators

    v(value)

  File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line 280, in __call__

    if self.compare(cleaned, self.limit_value):

  File "/usr/local/lib/python3.4/dist-packages/django/core/validators.py", line 319, in <lambda>

    compare = lambda self, a, b: a > b

TypeError: unorderable types: int() > str()

Best regards,

Santiago

[aRkadeFR]

Hey,

And is the CharField is really 16 char max_length in DB if
you specifiy a string '16'?

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users...@googlegroups.com.
To post to this group, send email to django...@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/7f920d86-1657-4922-a6a6-603ab0f846a3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
aRkadeFR

[Santiago L]

Yes, it is.

user=> \d+table django_foo;

                              Table "public.grd_device"

 Column |          Type          | Modifiers | Storage  | Stats target | Description 

--------+------------------------+-----------+----------+--------------+-------------

 id     | integer                | not null default nextval('django_foo_id_seq'::regclass) | plain   |  |

 bar    | character varying(16)  | not null  | extended |              | 

[James Schneider]

I'd post a bug report. Based on the behavior you've outlined (haven't looked at the Django source), there may have been some oversight on the duck typing that python performs. It sounds like the migration package is taking advantage of duck typing (since 16 == int('16')), but the validation functions are making comparisons on the assumption that 16 is an int, not a str.

If you really want to double check before filing, forward your question over to the dev mailing list.

This may be a good opportunity to provide a patch if you haven't done so before.

-James

To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/cf3c4d3e-e1be-4ed8-88e9-8bd2851676e6%40googlegroups.com.

[Santiago L]

El lunes, 18 de mayo de 2015, 12:33:21 (UTC+2), James Schneider escribió:

I'd post a bug report. Based on the behavior you've outlined (haven't looked at the Django source), there may have been some oversight on the duck typing that python performs. It sounds like the migration package is taking advantage of duck typing (since 16 == int('16')), but the validation functions are making comparisons on the assumption that 16 is an int, not a str.

FYI, bug report https://code.djangoproject.com/ticket/24818

Thanks all for your replies!