launchpad-dev team mailing list archive
-
launchpad-dev team
-
Mailing list archive
-
Message #04274
Re: "subscribe to search": implementation questions
On 12.08.2010 23:35, Robert Collins wrote:
> 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.
so, that would mean option 1, I think. The question remains if/how we
can efficiently include a clause "remove all subscriptions for the
current bug where the full text search filter does not match" in the One
Big query that returns all subscriptions. But issueing this query for
each possible subscription from Python would not cause that much more
load on the DB server, I think. After all, we are not talking about
rendering a web page but about a script.
>
> 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.
agreed
>
> 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 ;)
Nice suggestion -- I'll keep it in mind!
Abel
Follow ups
References