shaie commented on PR #841: URL: https://github.com/apache/lucene/pull/841#issuecomment-1155985365
> but the one bigger question I'd like to discuss is how we envision handing different point types? I think there are two sides of supporting additional numeric types: indexing and aggregation. IMO it's still fine if `FSM` handles a `long[]`: indexing `doubles` will be done as `toSortableLong` and reading `int` and `float` into `long` is doable. Therefore on the aggregation side I feel like it's fine to keep the `long[]` matching API. For indexing we just need to convert the values to `byte[]`. We can do that by making `FacetSet` abstract with a `toBytes()` method and the current impl will be changed to `LongFacetSet`. To complement that on the aggregation side we will need to pass a _reader_ which can convert the `BytesRef` to a `long[]`. I'm thinking that the `Int/Float/Long/DoubleFacetSet` impls will do that. As for "mix-and-match" I think this provides a solution too, since the user will be able to implement their own `FacetSet` and convert their, as example, `int, long, long, float` facet set to `byte[]` and decode that back. I'll give it a try to see how it works. -- 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
