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 -~----------~----~----~----~------~----~------~--~---
