Next I tried it with cPickle:
>>> from hubDatView import *
>>> mydatetime = getHubIndexUpdateDate(0)
>>> mydatetime
datetime.datetime(2007, 3, 3, 10, 51, 36,
tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0xb7781f4c>)
>>> import cPickle
>>> cPickle.dumps(mydatetime)
"cdatetime\ndatetime\np1\n(S'\\x07\\xd7\\x03\\x03\\n3$\\x00\\x00\
\x00'\ncpsycopg2.tz\nFixedOffsetTimezone
\np2\n(tRp3\n(dp4\nS'_offset'\np5\ncdatetime\ntimedelta
\np6\n(I-1\nI68400\nI0\ntRp7\nsbtRp8\n."
>>> cPickle.loads("cdatetime\ndatetime\np1\n(S'\\x07\\xd7\\x03\\x03\\n3$\\x00\\x00\\x00'\ncpsycopg2.tz\nFixedOffsetTimezone\np2\n(tRp3\n(dp4\nS'_offset'\np5\ncdatetime\ntimedelta\np6\n(I-1\nI68400\nI0\ntRp7\nsbtRp8\n.")
datetime.datetime(2007, 3, 3, 10, 51, 36,
tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0xb7781f8c>)
Seemed to work as well. Am I looking at the wrong thing? Why is
Pickling working here?
Any help is appreciated.
Thanks
On Apr 6, 2:46 pm, "paceman" <[EMAIL PROTECTED]> wrote:
> To try an see if the sqlalchemy datetime was causing the problem,
> I changed this session variable to a string. When I did this, the
> problem
> appeared to be gone, indicating that this is the cuprit.
>
> Next I called the routine by hand that gives the datetime, and played
> with it a bit:
>
> >>> from hubDatView import *
> >>> mydatetime = getHubIndexUpdateDate(0)
> >>> mydatetime
>
> datetime.datetime(2007, 3, 3, 10, 51, 36,
> tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0xb7770f4c>)>>> import
> pickle
> >>> pickle.dumps(mydatetime)
>
> "cdatetime\ndatetime\np0\n(S'\\x07\\xd7\\x03\\x03\\n3$\\x00\\x00\
> \x00'\np1\ncpsycopg2.tz\nFixedOffsetTimezone
> \np2\n(tRp3\n(dp4\nS'_offset'\np5\ncdatetime\ntimedelta
> \np6\n(I-1\nI68400\nI0\ntp7\nRp8\nsbtp9\nRp10\n.">>>
> pickle.loads("cdatetime\ndatetime\np0\n(S'\\x07\\xd7\\x03\\x03\\n3$\\x00\\x00\\x00'\np1\ncpsycopg2.tz\nFixedOffsetTimezone\np2\n(tRp3\n(dp4\nS'_offset'\np5\ncdatetime\ntimedelta\np6\n(I-1\nI68400\nI0\ntp7\nRp8\nsbtp9\nRp10\n.")
>
> datetime.datetime(2007, 3, 3, 10, 51, 36,
> tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0xb7776fec>)>>>
> mydatetime.tzinfo
>
> <psycopg2.tz.FixedOffsetTimezone object at 0xb7770f4c>>>>
> dir(mydatetime.tzinfo)
>
> ['__class__', '__delattr__', '__dict__', '__doc__',
> '__getattribute__', '__hash__', '__init__', '__module__', '__new__',
> '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__str__',
> '__weakref__', '_name', '_offset', 'dst', 'fromutc', 'tzname',
> 'utcoffset']
>
> I was trying to see if I could pickle and unpickle the datatime that I
> appear to have problems with, and to see if the tzinfo object had
> and __init__ method since the documentation mentioned in this
> discussion says that it must in order to successfully pickle and un-
> pickle.
> It appears to.
>
> Not sure why this works, if this is the problem. Perhaps I will try
> with cPickle next.
>
> On Apr 5, 5:20 pm, "paceman" <[EMAIL PROTECTED]> wrote:
>
> > Jeremy,
>
> > Thank-you for some more good tips.
> > The end of the error message is:
>
> > > > Can't pickle : it's not the same object as
> > > > psycopg2.tz.FixedOffsetTimezone
>
> > I am pretty sure there is nothing after that.
>
> > I will check into the sqlalchemy datetime wrt pickling. The error
> > appears to occur 50% of the time, but maybe the session
> > only gets pickled 50% of the time, and the pickling is failing all the
> > time. If it is expecting a psycopg2 datetime, but I am providing
> > a sqlalchemy datetime - don't know why it would be expecting the
> > psycopg datetime in the first place.
>
> > Thank-you for straightening me out on my misinterpretation of the
> > trace. I see what you mean. I may temporarily remove
> > the update_date and see if the problem goes away - an confirmation
> > that this is where the problem is.
>
> > On Apr 5, 3:59 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
>
> > > On 4/5/07, paceman <[EMAIL PROTECTED]> wrote:
>
> > > > One is an update_date
> > > > that comes from
> > > > a postgresql database
>
> > > Yes, the original error reported is:
>
> > > > > "/var/lib/python-support/python2.4/django/contrib/sessions/models.py",
> > > > > line 10, in encode pickled = pickle.dumps(session_dict) PicklingError:
> > > > > Can't pickle : it's not the same object as
> > > > > psycopg2.tz.FixedOffsetTimezone
>
> > > Which suggests that it has something to do with psycopg2. :)
> > > Unfortunately, it looks like part of your error message was eaten.
> > > There should be something just after "Can't pickle". Can you send
> > > that again?
>
> > > Anyway, the datetimes returned by psycopg2 are a subclass defined in
> > > psycopg2. The python docs actually have a specific admonition about
> > > pickling tzinfo:http://www.python.org/doc/2.3.5/lib/datetime-tzinfo.html
>
> > > psycopg2's tzinfo subclass implements this.
>
> > > Is it possible that the tzinfo attached to the datetime you're storing
> > > in the session is not picklable?
>
> > > >>> import psycopg2
> > > >>> c=psycopg2.connect("dbname=sekrit")
> > > >>> cur = c.cursor()
> > > >>> cur.execute('select current_timestamp')
> > > >>> r = cur.fet
> > > >>> r = cur.fetchone()
> > > >>> r
>
> > > (datetime.datetime(2007, 4, 5, 14, 46, 57, 754021,
> > > tzinfo=<psycopg2.tz.FixedOffsetTimezone object at 0xb776bfcc>),)
>
> > > >>> import pickle
> > > >>> pickle.dumps(r)
>
> > > "(cdatetime\ndatetime\np0\n(S'\\x07\\xd7\\x04\\x05\\x0e.9\\x0b\\x81e'\np1\ncpsycopg2.tz\nFixedOffsetTimezone\np2\n(tRp3\n(dp4\nS'_offset'\np5\ncdatetime\ntimedelta\np6\n(I-1\nI68400\nI0\ntp7\nRp8\nsbtp9\nRp10\ntp11\n."
>
> > > > What throws me off, is the pickling error seems to be complaining
> > > > about the Session cookie name which
> > > > is a datetime that django takes care of - not me.
>
> > > No, that's one line in the stack trace, but it's not the line with the
> > > error. That line forces pickling of the session object, which is
> > > where the problem is. It has nothing to do with the cookie. :)
>
> > > > I thought I was using straightforward django technique, except for
> > > > using sqlalchemy to access
> > > > my database tables.
>
> > > Hmm, I have no idea how SQLAlchemy is constructing its datetime
> > > instances. It would probably be worth looking at, since using
> > > SQLAlchemy is probably fairly unusual with Django+psycopg2.
>
> > > -Jeremy
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
