[Stephen Masterman]
> Does ZODB have something equivalent to Durus' Computed Attributes? Which
> I understand are attributes (or methods) on a Persistent object that
> compute a value from some other attributes and then cache that result for
> each connection, and if any of the attributes from which the Computed
> Attribute computes its result change, the new result will be
> automatically computed and all connections will have their cached value
> invalidated.
I don't know. My understanding is that ComputedAttribute (one word) is a
subclass of Persistent in Durus. I haven't used it, and I don't understand
the explanations I found online.
> On a related note, do properties work with Persistent objects in ZODB? I
> mean the Python property() function. I do not know how it interacts with
> __getattr__() and stuff, and I know the ZODB docs warn against messing
> with those functions for Persistent classes.
Which ZODB docs do you have in mind? I'm not disputing them <wink>, I just
have no idea what you've been reading, since I don't think the ZODB/ZEO
Programming Guide mentions this, and that's about the only semi-official
ZODB user documentation that exists:
http://www.zope.org/Wikis/ZODB/FrontPage/guide
> If they do work, do they basically serve as a non-cached computed
> attribute?
In general, I don't expect most "newer" Python class features (like
properties) to work in any ZODB before 3.3. Persistent was an
ExtensionClass then, which is a dark maze of C code designed long before the
newer Python class features. OTOH, I expect newer class features to work in
ZODB >= 3.3, where Persistent is a "vanilla" new-style Python class.
What a property "serves as" depends 100% on the code you write to implement
one. Python's property mechanism just gives you a way to intercept attempts
to set, get, or delete an attribute -- what you do then is entirely up to
you. Here's an example (which I just wrote & run under ZODB 3.4) where the
property "product" acts like a cached, computed, read-only attribute:
"""
import ZODB
import transaction
from persistent import Persistent
class MagicalProduct(Persistent):
_v_cached = None # instance sees this if it doesn't have its own
def __init__(self, a, b):
self.a, self.b = a, b
def __product(self):
if self._v_cached is not None:
print "gotten from cache"
return self._v_cached
print "computed fresh"
result = self._v_cached = self.a * self.b
return result
product = property(__product)
from ZODB.FileStorage import FileStorage
st = FileStorage("product.fs")
db = ZODB.DB(st)
cn = db.open()
p1 = MagicalProduct(3, 5)
print p1.product # computed fresh; 15
print p1.product # gotten from cache; 15
cn.root()['p1'] = p1
transaction.commit()
cn2 = db.open()
p2 = cn2.root()['p1']
print p2.product # computed fresh; 15
print p2.product # gotten from cache; 15
p1.a = 12
transaction.commit()
print p1.product # NOTE WELL: gotten from cache; 15
print p2.product # computed fresh; 60
"""
There's lots going on in the last two lines. First, _v_ attributes (like
_v_cached above) are special to ZODB, and get destroyed "by magic" when an
object is unloaded:
http://www.zope.org/Wikis/ZODB/VolatileAttributes
We got 15 in the penultimate line because a connection does not send
invalidation messages to itself; it thinks it already has up-to-date state.
That cn2 saw the invalidation "by magic" relies on a new ZODB 3.4 feature
(in current SVN 3.4 branch; not yet in a released tarball/installer): a
transaction object now calls registered afterCompletion() methods after a
transaction commits or aborts, and Connections register with transactions in
3.3+, and their afterCompletion() methods process invalidations in 3.4+. In
3.3, you would need to do (e.g.) an explicit cn2.sync() for the last line to
print 60 instead of 15.
> Is a Durus Computed Attribute just a property with caching and
> consistency for multiple connections? (I know this isn't a Durus list.)
Sorry, don't know.
> I'm developing an application for my job that uses ZODB. I think ZODB is
> awesome and it has been very instructive studying the code and
> documentation and the archives for this list. So thanks all you people
> who write this great software and help others understand it.
You're welcome!
> I eventually hope to produce something useful for less experienced
> programmers (like me) about indexing strategies and techniques. Indexing
> turns out to be somewhat complicated with important tradeoffs to
> consider.
If you're still thinking just "somewhat", your ambitions still have plenty
of room to grow <wink>.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
