kotman12 commented on issue #14886: URL: https://github.com/apache/lucene/issues/14886#issuecomment-3045560479
> In that case I ended up writing my own hash function, but it needs to be specialized for each Query type, and isn't really a general solution Thanks @msokolov, even if it is unrelated can you share this anyway? In the case of this issue specifically I feel that we will either have to have something "specialized" or just remove/disallow the combination of features that rely on hash ordering across JVMs. It could be very well that some specialized ordering is good enough for now. It will likely will be different from what you came up with for your other use case but it would be a good reference nonetheless.. For context, in the case of lucene-monitor the feature that relies on hashcode ordering _also_ relies on term query "leaves" (all _current_ lucene monitor optimizations work specifically on term queries AFAIK). So in this case a clause (or clause group) identifier derived from the terms of a `Query` seems to apply to the lucene-monitor case with some caveats. The downside is it is complex and only useful for queries with predominantly term query clauses. The upside is it should work for generic `Query`s via `visit` ev en if it is not optimal for many of them (AFAIK lucene-monitor has no optimizations for non-term queries anyway) -- 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
