On 22-6-2012 12:58, Bram de Jong wrote: > On Fri, Jun 22, 2012 at 12:27 PM, Melvyn Sopacua <m.r.sopa...@gmail.com> > wrote: >> On 22-6-2012 12:09, Bram de Jong wrote: >> >>> However, when I turn this field into a filter in the admin, instead of >>> seeing the filter-versions as my string (i.e. "1.0.5rc3") I see it as >>> the underlying database type (i.e.10000301) >> >> I suspected there is another code path that doesn't call to_python >> properly, but let's rule out it's not the same as my issue: >> Is this field a foreign key for the model that's being displayed? > > It isn't. > > Where should I be digging to figure out the code path being called? > > Additionally clicking the filter will make things crash because I'm > getting a string which is "10000301" if I do. > > Just to rule out simple stupidity on my part, here's the model field > and form field I'm using.
You should not be getting integer instances in get_prep_lookup(). That's your initial debugging point. I have a similar field (integer rep in database and string rep in python) and I'll check if I can reproduce your case, once I get back to that machine. To get this bug[1] traced down, I created a logger in settings.py and inserted logging statements and assert(1==2) in the code paths. But there are some __magic__ methods involved that don't backtrace well, so that's where logging comes in. If it's the same root cause as my bug, implement value_from_object on your field and call to_python on the value argument. [1] https://code.djangoproject.com/ticket/18501 -- Melvyn Sopacua -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
