|
From: Bud P. B. <bu...@si...> - 2003-05-26 09:47:31
|
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 |
