May I propose Query Index? On Thu, May 2, 2024 at 3:03 PM Gus Heck <gus.h...@gmail.com> wrote:
> It detects documents that match a set of queries, so maybe "detector"? > > On Thu, May 2, 2024 at 4:30 AM Jan Høydahl <jan....@cominvent.com> wrote: > > > Alerting, while overloaded is probably the most precise name we could > > choose - documentation would help explain the scope. > > And if someone made an example project with a UI for experimentation that > > would make the feature much more approachable. > > > > Jan > > > > > 2. mai 2024 kl. 03:18 skrev Walter Underwood <wun...@wunderwood.org>: > > > > > > The functionality is alerts, but that doesn’t mean it has to be a push > > API. Alerts can be fetched just as easily as pushed. > > > > > > I don’t know the limits of this proposal, but LexisNexis needs alerting > > as we move all of our 114 billion documents onto Solr. I’m retiring this > > week, so I won’t be around to implement it, but that is one potential > large > > customer. > > > > > > wunder > > > Walter Underwood > > > wun...@wunderwood.org > > > http://observer.wunderwood.org/ (my blog) > > > > > >> On May 1, 2024, at 2:26 PM, Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) > < > > lkotzanie...@bloomberg.net> wrote: > > >> > > >>> I kind of like "search-alerts". "query-alerts" sounds like alerting > on > > >>> query metrics, but IMO "search-alerts" doesn't come with the same > > baggage. > > >> > > >> Someone in the PR had mentioned that "alerts" is a bit off because the > > proposal does not really manage alerts and it feels too far out of solr's > > domain. The current approach, much like percolator, simply exposes a > > request/response API that then can be **used** by an alerting system > > (request/stream<response> could also be considered if there is worry > about > > scaling the number of queries one request can match). > > >> > > >>> I think this is certainly something that can start in the sandbox and > > move> into the main repo once it's clear that there is interest from > > >>> multiple committers and community members in using and maintaining > it. > > >> > > >> I've seen many homegrown/complex solutions of percolator-type > > functionality so even this narrower "inverted search" solution has > **some** > > use but admittedly this is a niche area. It might not really gain > traction > > unless it is marketed the right way as there are probably very few solr > > users that happen to be thinking about revamping their saved-search > > platform in any given year. Given that, what do you think I can do to > reach > > them? :-) > > >> > > >> I am trying my best to talk about this within my firm but the sample > is > > obviously smaller. > > >> > > >> From: dev@solr.apache.org At: 05/01/24 16:16:50 UTC-4:00To: > > dev@solr.apache.org > > >> Subject: Re: solr query alerting > > >> > > >> I think I'd prefer a more self-descriptive name than "Luwak", which is > > just > > >> a product name that was decided a while ago. > > >> > > >> I kind of like "search-alerts". "query-alerts" sounds like alerting on > > >> query metrics, but IMO "search-alerts" doesn't come with the same > > baggage. > > >> > > >> Luwak is fine though if everyone agrees on that. > > >> > > >> On one hand we have a number of committers here from > > >>> Bloomberg, yet the abandoned and now-removed "analytics" component > > >>> shows that abandonment is a risk nonetheless. > > >>> > > >> > > >> I don't want to bikeshed here, but I'm not sure this is a fair > > >> assessment of what happened with the analytics module. > > >> Sure there wasn't a ton of development, but in general it was feature > > rich > > >> and had very little feature requests. > > >> It was removed in 10, because a lack of user usage, not because it was > > >> "abandoned" IMO. If there were requests from users > > >> to keep it or improve it, then it would be a much different story. The > > >> whole "thrown over the wall" comment is fair, but > > >> not particularly relevant to this PR, which is being worked on in > > public. > > >> > > >> I think this is certainly something that can start in the sandbox and > > move > > >> into the main repo once it's clear that there is interest from > > >> multiple committers and community members in using and maintaining it. > > >> > > >> - Houston > > >> > > >> On Wed, May 1, 2024 at 2:32 PM David Smiley <dsmi...@apache.org> > wrote: > > >> > > >>> Luwak is good to me! > > >>> > > >>> On Tue, Apr 30, 2024 at 4:01 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 > 3RD > > >>> A) <lkotzanie...@bloomberg.net> wrote: > > >>>> > > >>>> I love the name "luwak"! I was about to suggest the same but was > > worried > > >>> about the trademark concerns and I assumed there was a reason they > > changed > > >>> the name when donating it to lucene. > > >>>> > > >>>> From: dev@solr.apache.org At: 04/30/24 15:56:22 UTC-4:00To: > > >>> dev@solr.apache.org > > >>>> Subject: Re: solr query alerting > > >>>> > > >>>> Luwak is the original name of the Lucene monitor, contributed by > Flax > > >>> back in > > >>>> the days: https://github.com/flaxsearch/luwak > > >>>> > > >>>> Perhaps we could go full circle (if no trademark issues) to call it > > the > > >>> Solr > > >>>> luwak module? Luwak is a type of coffee, and thus related to > > percolator > > >>> 😉 > > >>>> > > >>>> Otherwise “stored-queries” is an option. > > >>>> > > >>>> Jan Høydahl > > >>>> > > >>>>> 30. apr. 2024 kl. 19:26 skrev David Smiley <dsmi...@apache.org>: > > >>>>> > > >>>>> I agree the feature is relevant / useful. > > >>>>> > > >>>>> Another angle on the module vs sandbox or wherever else is > > maintenance > > >>>>> cost. If a lot of code is being contributed as is here, then as a > > PMC > > >>>>> member I hope to get a subjective sense that folks are interested > in > > >>>>> maintaining it. On one hand we have a number of committers here > from > > >>>>> Bloomberg, yet the abandoned and now-removed "analytics" component > > >>>>> shows that abandonment is a risk nonetheless. I don't know how to > > >>>>> conclude this thought but I'm hoping to hear from folks that they > > >>>>> intend to look after this module. It's not just being "thrown over > > >>>>> the wall", so to speak. > > >>>>> > > >>>>> Naming is hard... > > >>>>> * ...-monitor-....: sorry I hate it > > >>>>> * ...-percolator-.... No clue why this was chosen for > ElasticSearch. > > >>>>> I can appreciate a curious/non-obvious name like this that is not > > >>>>> going to conflict with anyone's guesses at what a general name > might > > >>>>> convey. > > >>>>> * "indexed-queries" or "query-indexing" would be a good name? This > > is > > >>>>> the best technical name I can think of. > > >>>>> * "reverse search" came to mind (based on the Netflix article) > > >>>>> although that makes me think of leading-wildcard / suffix-search. > > >>>>> * "inverted-search" > > >>>>> * "indexed-query-alerts" incorporates "alerts" thus might better > > >>>>> convey the use-case > > >>>>> > > >>>>>> On Mon, Apr 1, 2024 at 3:53 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 > > 3RD > > >>>>>> A) <lkotzanie...@bloomberg.net> wrote: > > >>>>>> > > >>>>>> Hi All, > > >>>>>> > > >>>>>> A few months ago I wrote the user list about potentially > integrating > > >>> lucene > > >>>> monitor into solr. I have raised this PR with a first attempt at > > >>> implementing > > >>>> this integration. I'd greatly appreciate any feedback on this even > > >>> though I > > >>>> still have it marked as draft. I want to make sure I'm heading in > the > > >>> right > > >>>> direction here so input from solr dev community would be extremely > > >>> valuable :-) > > >>>>>> > > >>>>>> Many thanks, > > >>>>>> Luke > > >>>>> > > >>>>> > --------------------------------------------------------------------- > > >>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > >>>>> For additional commands, e-mail: dev-h...@solr.apache.org > > >>>>> > > >>>> > > >>>> > > >>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > >>> For additional commands, e-mail: dev-h...@solr.apache.org > > >>> > > >>> > > >> > > >> > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org > > For additional commands, e-mail: dev-h...@solr.apache.org > > > > > > -- > http://www.needhamsoftware.com (work) > https://a.co/d/b2sZLD9 (my fantasy fiction book) > -- Sincerely yours Mikhail Khludnev
