Re: [SQLObject] Thoughts on how to get from values to objects

[Bud P. B. <bu...@si...>]

On 25 May 2003 02:05:34 -0500
Ian Bicking <ia...@co...> wrote:

> On Thu, 2003-05-22 at 16:10, Bud P.Bruegger wrote:
> > I'm wondering what pickle does--it's kind of the same problem.  Does
> > it call __init__ during unpickling or just __new__???  While I haven't
> > looked into the details, I'm quite positive the latter holds..
> 
> I don't know what exactly it does, but it doesn't call either __init__
> or __new__ -- I believe it calls __setstate__, if you want to change how
> pickle works on your object.

I just looked it up and by default, it saves and restores the values
of __dict__ without calling __init__.  If one wants __init__ to be
called, __getinitargs__() needs to be provided and the resulting tuple
is stored as part of the pickle.  

__getstate__ and __setstate__ seem to be used if other values than the
object's __dict__ need to be stored...

...

> The reality is that there is a disconnect between database objects and
> Python objects.  SQLObject doesn't provide an object store, ala ZODB. 
> It maps, but there's no expectation that it will be perfect -- so
> creating a Python object from the database row *is* a
> creation/construction operation, it's not just like we've just brung the
> object into memory from a different storage mechanism (as with pickle or
> ZODB).

I think I agree with this.  The Attribute layer that in my proposed
architecture sits between a class and the columns actually makes this
process explicit  (I have toSQL and fromSQL functions).  Still, in
most cases, I believe these will not be necessary and the default
functions really just say to store and restore the __dict__.


> Personally I find properties a little funny to work with anyway. ...

I agree.  My incentive is to impose as few limitations on classes that
can be made persistent as possible..


> Using *Python* convention, if you want to ensure consistency you do so
> *as each attribute is set*.  People don't write Python objects that have
> some uncommitted/committed state, where verification is delayed until
> the commit.
> 
> If you need to check consistency among several attributes, you set them
> all at once.  I don't see a problem with that -- it's what I do for
> non-database objects already.  

hmm. you are probably right here unless the app has a need for long
transactons...

thanks for your feedback

--b