[Zope-dev] References, persistence, BTrees

[kapil thangavelu]

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