Karen: Yaaaaayyy!!! Thank you!
On Sep 23, 11:45 am, Karen Tracey <[email protected]> wrote: ... > /home/kmt/software/web/playground/ttt/newfields.py(56)to_python() > > -> utc_dt = super(DateTimeFieldInTZ, self).__init__(value, *args, **kwargs) ... > I don't actually have a clue what the code here is trying to do, but what it > ends up doing is returning None, which would seem to be wrong. Calling the > superclass __init__ from the to_python method seems a bit odd, though? Did > you mean to rather call its to_python? Ahem, yes, that would be absolutely right. This call should be to the superclass's to_python(): > super(DateTimeFieldInTZ, self).to_python(value, *args, **kwargs) The proximate cause of failure is that the superclass was returning None. The next cause is that __init__() doesn't have a return statement, so if you collect a value from it, as I did, the value will be none. The ultimate cause of failure is my copy/paste goof. I wrote the superclass call for __init__(), then pasted it into to_python() and get_db_prep_value(), and forgot to fix up the method name once. Sloppy. > > Diagnosis is made a little harder, because my Eclipse + PyDev setup > > cannot step all the way through to these errors. I get a different > > failure in the debugger, and it happens in the midst of stepping to > > the next line, so I don't see the point of error. > > > Thanks for any light anyone can shed! I appreciate the help. > > Eclipse+PyDev has to do a lot of behind-the-scenes stuff to populate the > variables window, etc. When there are basic problems with pretty low-level > stuff it can at times get confused. In those cases its usually easier to > rely on something more basic, like pdb, to figure out what is going on. It > may not be as pretty, but it can get the job done without going off into the > weeds. ... >....I put an import pdb; pdb.set_trace() right before the call to > the superclass method, attempted to create an instance of a model with one > of these fields from a Python shell, and stepped through in the debugger to > see where it went:... This is very good advice. I've learned two things from you today. Thank you, Karen. — Jim DeLaHunt, Vancouver, Canada On Sep 23, 11:45 am, Karen Tracey <[email protected]> wrote: > On Wed, Sep 23, 2009 at 12:47 PM, Jim DeLaHunt <[email protected]>wrote: > > > > > > > Karen: > > > Thank you so much for your reply. > > > On Sep 23, 7:01 am, Karen Tracey <[email protected]> wrote: > > > What you haven't shared is the code for DateTimeFieldInTZ. It's going to > > be > > > rather hard to figure out what is going wrong without seeing that code. > > ... > > > If you show us what is in the DateTimeFieldInTZ implementation it's much > > > more likely that someone will be able to help. > > > Ah, right you are. Here's the custom field in question. > > > ===== datetimefieldintz.py: > > [snip] > > > I wrote this class while going over the definition of > > models.DateTimeField in django/db/models/fields/__init__.py:526-583. > > > One interesting observation about the diagnostic print statement in > > get_db_prep_value(). It prints out, > > @@@ get_db_prep_value( <type 'datetime.datetime'>(2009-06-30 > > 23:59:45+00:00) ) begins. > > @@@ get_db_prep_value( 2009-06-30 23:59:45+00:00 ) got None back from > > superclass > > Making it look like models.DateTimeField.get_db_prep_value() is > > choking on <type 'datetime.datetime'>(2009-06-30 23:59:45+00:00) (with > > a utc tzinfo). > > Since you then proceed to return what the superclass has returned, that > explains why you are getting an IntegrityError on the field that isn't > allowed to be NULL. You are returning None, which will turn into an attempt > to set the field to NULL in the database. > > The question, then, is why is the call to the superclass returning None? To > get some idea, I put an import pdb; pdb.set_trace() right before the call to > the superclass method, attempted to create an instance of a model with one > of these fields from a Python shell, and stepped through in the debugger to > see where it went: > > >>> from ttt.models import Special > >>> import datetime > >>> x = Special.objects.create(special_date=datetime.datetime.now()) > > @@@ get_db_prep_value( <type 'datetime.datetime'>(2009-09-23 > 14:30:04.249914) ) begins.> > /home/kmt/software/web/playground/ttt/newfields.py(102)get_db_prep_value() > > -> r = super(DateTimeFieldInTZ, self).get_db_prep_value(value, *args, > **kwargs) > (Pdb) s > --Call-- > > /usr/lib/python2.5/site-packages/django/db/models/fields/__init__.py(567)get_db_prep_value() > -> def get_db_prep_value(self, value): > (Pdb) s > > /usr/lib/python2.5/site-packages/django/db/models/fields/__init__.py(569)get_db_prep_value() > -> return connection.ops.value_to_db_datetime(self.to_python(value)) > (Pdb) s > --Call--> /home/kmt/software/web/playground/ttt/newfields.py(46)to_python() > > -> def to_python(self, value, *args, **kwargs): > > Note it's coming right back to your to_python() method for this field. > > (Pdb) s> /home/kmt/software/web/playground/ttt/newfields.py(53)to_python() > > -> skip_tz = isinstance(value, datetime.date) > (Pdb) s> /home/kmt/software/web/playground/ttt/newfields.py(56)to_python() > > -> utc_dt = super(DateTimeFieldInTZ, self).__init__(value, *args, **kwargs) > (Pdb) n> /home/kmt/software/web/playground/ttt/newfields.py(60)to_python() > > -> if utc_dt is None or skip_tz: > (Pdb) utc_dt > (Pdb) skip_tz > True > (Pdb) n> /home/kmt/software/web/playground/ttt/newfields.py(61)to_python() > > -> return utc_dt > (Pdb) n > --Return--> > /home/kmt/software/web/playground/ttt/newfields.py(61)to_python()->None > > -> return utc_dt > (Pdb) c > > I don't actually have a clue what the code here is trying to do, but what it > ends up doing is returning None, which would seem to be wrong. Calling the > superclass __init__ from the to_python method seems a bit odd, though? Did > you mean to rather call its to_python? > > Here's the entire traceback of the first failure in the Django built- in > > > tests: > > > [snip] > > I don't know that it is worth debugging this until you've got the basic > save() working. > > > > > Diagnosis is made a little harder, because my Eclipse + PyDev setup > > cannot step all the way through to these errors. I get a different > > failure in the debugger, and it happens in the midst of stepping to > > the next line, so I don't see the point of error. > > > Thanks for any light anyone can shed! I appreciate the help. > > Eclipse+PyDev has to do a lot of behind-the-scenes stuff to populate the > variables window, etc. When there are basic problems with pretty low-level > stuff it can at times get confused. In those cases its usually easier to > rely on something more basic, like pdb, to figure out what is going on. It > may not be as pretty, but it can get the job done without going off into the > weeds. > > Karen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" 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-users?hl=en -~----------~----~----~----~------~----~------~--~---
