kotman12 commented on PR #13993: URL: https://github.com/apache/lucene/pull/13993#issuecomment-2481770909
> The monitor was initially written as a stand-alone application, and I didn't have integrations in mind at all when I was designing the API. But we can definitely re-work things a bit so that there are library functions as well as executable ones. Yes, as far as I can tell it is widely used as an application for fast query alerting and/or saved search. The API works fine for most stand-alone applications. > I guess what we really need is something that takes a Query and produces a Document, for the index-time side of things; \+ > takes a set of Documents and rewrites itself into the presearcher query I'd say these two are the most important features for the library API to have in order to easily fit into something like Solr, at least the way I was envisioning. > and an extensible CollectorManager that calls an abstract method whenever it gets a candidate match. Having any kind of hook into the `CandidateMatcher` would be beneficial. I am not opposed to an IoC style I think you are suggesting. I assume the motivation for the callback-style API is because the CandidateMatcher can be async, i.e. in the `ParallelMatcher`? Either way, I think I'm on-board. Currently I create a new `CandidateMatcher` with each doc and call `finish` on each doc individually which is a bit cumbersome. > and then a SearcherManager/IndexSearcher implementation that handles the QueryTermFilters Having a `QueryTermFilter` per `IndexSearcher` makes sense from a lucene perspective. Unfortunately, Solr inherits its own `IndexSearcher` so this wouldn't easily apply to the Solr use-case although that is not to say it is a bad idea. It might be beneficial (at least for the Solr use-case) to also expose the `QueryTermFilter` itself ... I know it's not a lot of code but it would be nice to not copy it. Solr could effectively manage its own QTF at the Solr searcher-level (currently I have it shared between many searchers which is not correct ..) Obviously you are the best equipped person to make these changes and decisions on the lucene-monitor API but if you would like any help let me know! Either way thanks for taking a look. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
