launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04252
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