← Back to team overview

launchpad-dev team mailing list archive

Re: "subscribe to search": implementation questions

 

Clint, thanks for sharing your experience there - a very close mapping
as you say :)

Abel, I don't have a particular answer for you just yet - I will read
up in more detail.

I do have a few constraints that a quick glance at the LEP suggests are missing.

Firstly, we need to be able to send the notifications for a changed
bug effiicently - I don't mean 'send the mails', I mean 'the time to
determine who is subscribed' should be very low.

At the moment, I think we take only 2 queries to get the subscribers
via direct and structural subscription. We should set a budget - say 1
query - to get the subscribers via this new mechanism. This will
inform the design :)

Secondly, because we can reasonably expect lots of subscriptions, we
should require that what comes back from the DB is either precisely
the subscribers, or only slightly more: if we bring back 300
subscribers and then filtered that down to 150 in python, it would get
pretty slow pretty quickly.

On Clint's point of schema migration, I'm not -too- worried - but it
will be a cost; we definitely don't want to make it harder to improve
things elsewhere in the system.

I'd *love* to also raise a signal to all the RSS feeds
(pingthesemanticweb) for an altered bug. So if you can see how to
calculate that at the same time as part of this work - well that would
be _awesome_. If its unrelated obviously don't go out of your way to
think about it ;)

-Rob



Follow ups

References