Re: [SQLObject] Identity crisis.

[Ian B. <ia...@co...>]

Alan Kennedy wrote:
> [Alan Kennedy]
>  >> I'm trying to pickle SQLObjects, so that I can store them in
>  >> structured documents. As far as I can see, pickles only need to
>  >> contain the name of the SQLObject class, and the id which uniquely
>  >> identifies the instance.
> 
> [Brian Ray]
>  > I thought SQLObject does not support pickleing because it uses pickel
>  > for persistance:
>  >
>  > http://sourceforge.net/mailarchive/message.php?msg_id=7578480
> 
> Thanks for pointing out that reference Brian, I hadn't seen it before.
> 
> Looking at Ian's message at that url, it looks like he's talking about 
> support for pickling the entire SQLObject, which I would imagine would 
> have complex consequences when it comes to connections, etc, because 
> object identity seems to be related to the connection that the object 
> came from.

I was just thinking about a reference (i.e., no column data).  The 
reference might or might not include the connection; both instances have 
valid use cases.  E.g., the connection may often be configurable, and if 
you change the configuration and load the pickle you may want lot load 
it from the newly configured connection, not the old connection.  OTOH, 
if you are using multiple databases, you may want the connection 
included in the reference.

__setstate__ would require refactoring SQLObject a bit, so that it could 
set up all the special variables that SQLObject creates in __init__. 
That would be doable.  Another option would be to implement __new__, and 
potentially include some magic keyword argument that would cause a 
.get() to be called.  Of course, __init__ gets *re*-called if __new__ 
returns an instance of the class.  Frankly __new__ is a stupid, stupid 
method.

Which makes me think __setstate__ may be the better way to go.  Oh, 
wait, no... that's no good either.  Because sometimes you'll be 
returning an existing instance when unpickling, if that row has already 
been loaded up.  Blah.  And what if you want to load the objects into a 
transaction?  Then you'd want to say, "unpickle to this connection". 
Again, rather annoying, since there's no way to pass information from 
the pickler into the class, except through a global.

At that point, a pickle subclass starts to seem better, where this 
configuration information could be stored in the pickle subclass.

Blah.  Well, there's my indecisive opinion.

-- 
Ian Bicking  /  ia...@co...  / http://blog.ianbicking.org