gsmiller commented on PR #841: URL: https://github.com/apache/lucene/pull/841#issuecomment-1152648521
> So again, purely from an API perspective, we tell the user "You give us long[] at indexing time, we'll give it you back at aggregation time". It's simple, readable, intuitive. Hmm, yeah this is a good point. +1 that it would be more intuitive for users to implement a long-based match method if they're writing their own `FSM` implementations. And +1 that it also provides a layer of separation between the encoding and the logic (so we could change the encoding of the point doc values without breaking `FSM`s). I pushed a change just now that shows a different way we _could_ approach this. I'm not sure I think we _should_, but wanted to float it out there to see what you all think. I'm also not opposed to moving forward with _only_ a long-based API and then benchmark to see if the byte-based approach is _actually_ more optimal. Honestly, that's probably the right decision here... -- 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
