mdmarshmallow commented on PR #841: URL: https://github.com/apache/lucene/pull/841#issuecomment-1148250328
> We could totally offer that out-of-the-box, but I prefer that we do so in a different PR. Not sure about the API details yet, and whether it can truly be a generic impl or not, but it's totally something we should think about. This sounds like a good idea, I agree > Indeed, implementing your own FacetSetMatcher is expert? Ok, if this is the case, then should we provide more out of the box `FacetSetMatcher` classes (like a `double` and a `long` implementation for starters). > Extending FSM is what you refer to here? This is indeed the more expert API, which I hope users won't have to extend, given the OOTB classes. Yes I am referring to extending FSM, but as I said we should probably supply more OOTB classes in this case? > For this reason I don't think FSM should make you read the bytes into longs, let the impl do that if it's more convenient for it. Ah I see your complaints here. Yeah my goal was trying to make this less of an "expert" API, but if we are going to treat overriding `matches()` as an expert API and provide more OOTB classes, that makes sense. But one thing I want to point out that I was also thinking is that if we are able to read all `bytes[]` into `longs[]`, we can do some stuff with R-trees in `MatchingFacetSetCounts` like put all the FSM into an R-tree for faster matching. If we make it so that the data in an FSM isn't guaranteed to be able to be turned into a long, we can't do this optimization in the future. > Do you see more than two impls here? I could, for example if they wanted to encode String ordinals here where the ordinals are long, they can write that conversion logic in `writeToLong(String... values)`. With that being said, as you mentioned earlier this enforces encoding in longs which we do want to avoid right? -- 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
