Thank-you for the demonstration.  Makes it much clearer, and sent
me back to my 'Python In A Nutshell' book.

The function I call to get the datetime, in turn, calls sqlalchemy
functions:
******************************************************************
def getHubIndexUpdateDate(file_id):
    """
    This function looks at the hubindex table for the record
containing 'file_id' and returns the update_date field of that record.
    This date is used to prevent database update concurrency issues.
The date will be used to determine
    if the records have been updated since a particular user read
them.  If so, it will not allow the user to
    update the records.
    """

    (engine, hubindextable, vhubdisptable) = hubutil_conn()
    result =
hubindextable.select(and_(~(hubindextable.c.filename.like('%\\_var\\_
%')),hubindextable.c.file_id == file_id)).execute()
    myrec = result.fetchone()

    return myrec['update_date']
************************************************************

I am thinking sqlalchemy must recreate the class tzinfo everytime it
is called, and this is messing up the Pickling.  Not sure
how to get around this, except creat my own datetime instance of a
class that does not change and assign the results to
that instance.  Going back to the sqlalchemy documentation may also
provide some clues.
The hubutil_conn() function has a firsttime flag, so it only actually
connects the first time.

What do you think?


On Apr 6, 3:54 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> On 4/6/07, paceman <[EMAIL PROTECTED]> wrote:
>
>
>
> > I guess what I am beginning to realize is that everytime I call my
> > mydatetime = getHubIndexUpdateDate(0), I get a new
> > tz.FixedOffsetTimezone object at xxxx, noting the xxxx.
>
> Well, if using ctime is workable for you, it's certainly a way to
> avoid the problem.
>
> But no, what you're seeing there is that there are different tzinfo
> *instances*.  Yet what pickle is complaining about is different tzinfo
> *classes* of the same name.
>
> In python, everything is an object, including types.
>
> A little demonstration:
>
> >>> i = 1 #Make i an instance of type int.
> >>> type(i) #see?
>
> <type 'int'>
>
> >>> t=type(i) #make t be a reference to the type object.
> >>> id(t) #what is the id of t?
>
> 135359904
>
> >>> class C(object): #make a new type, class C.
>
>    ...:     pass
>    ...:
>
> >>> id(C)  #what is the id of C?
>
> 136773772
>
> >>> c=C() #make c be an instance of type C.
> >>> id(type(c)) is id(C) #verify that the type of c is, indeed, what
>
> we currently call C.
> True
>
> >>> class C(object): #re-define C to be some other type.
>
>    ...:     pass
>    ...:
>
> >>> id(C) #note that the id of type C has changed.
>
> 136788340
>
> >>> id(type(c)) is id(C)
>
> False
>
> Under these conditions, pickle will fail to dump "c" because the type
> it refers to no longer has a name.  type(c) is *not* what we call "C"
> any longer.  Pickle has no way to re-construct the instance c, since
> it'd need a way to refer to the type formerly named C.
>
> See?  :)


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

Reply via email to