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)

Reply via email to