[Zope-dev] References, persistence, BTrees
kapil thangavelu
k_vertigo@yahoo.com
Sat, 5 Jan 2002 16:07:42 -0800
Hi jeffrey,
perhaps it might save you a bit of trouble. i've written a publish/subscribe
event channel that seems to have must of the functionality listed below
although it does use the techniques that you wanted to avoid. its at
http://www.zope.org/Members/k_vertigo/Products/EventChannel
at the moment its purposefully a simple publish subscribe model with filters.
object references are stored via physical path and resolved via
unrestrictedTraverse.
On Thursday 03 January 2002 04:49 pm, Jeffrey P Shell wrote:
> I'm experimenting with an event notification service based on a
> publish-subscribe model for some projects I'm working on. When a
> subscription comes in, a 'Subscription' object is made, that
> basically looks like this:
>
> class Subscription(Base):
> def __init__(self, subscriber, eventType, filter=None):
> self.subscriber = subscriber
> self.eventType = eventType
> self.filter = filter
>
> def __hash__(self):
> return hash(self.subscriber) & \
> hash(self.eventType) & \
> hash(self.filter)
>
> 'subscriber' is a reference to the subscribing object, and it's
> very likely to be to an object in the ZODB. Is it wise to have
> more than one persistent reference to a single persistent object?
> I swear that I had once heard Jim say (vocally) that you could do
> references like this in the ZODB now. I'm trying to avoid using
> Paths because objects have a tendency to move around[*], and I have
> performance concerns for a single event service object to have to
> call 'unrestrictedTraverse' to every subscriber.
yes, this a concern and depends on usage. i generally don't have many
listeners to a particular event. when this has been an issue, i instead
chain event channels and stick events in an event queue, which periodically
gets flushed from a zeo client script. currently i'm doing this for a
subscription model which works well since the subscriptions that way get sent
out all at once, instead of bombarding the end user with lots of emails.
> [*] (it's due to the annoyances with manage_beforeDelete() and
> friends that
> I'm writing this tool.)
>
> Second question: If I use the hash of the Subscription as a key, is
> there any advantages/disadvantages with using an IOBTree to hold
> Subscription objects instead of a PersistentMapping?
memory usage would probably be an advantage over large numbers of
subscriptions, but i'm not qualifed to answer...
cheers
kapil