I think we should assert that the seekCeil returned SeekStatus.FOUND?
Ok! I'll commit that.
useCache is an ancient option from back when we had a terms dict cache
Yes, I suppose is is not 'clear' to have this parameter.
seekExact is working as it should I think.
Currently, I think those 'seek' methods are supposed to change the enum pointer based on
input term string, and fetch related metadata from term dict.
However, seekExact(BytesRef, TermsState) simply 'copy' the value of termState to enum, which
doesn't actually operate 'seek' on dictionary.
Maybe instead of term and meta members, we could just hold the current pair?
Oh, yes, I once thought about this, but not sure: like, can the callee always makes sure that,
when 'term()' is called, it will always return a valid term?
The codes in MemoryPF just return 'pair.output' regardless whether pair==null, is it safe?
TempMetaData.hashCode() doesn't mix in docFreq/tTF?
Oops! thanks, nice catch!
It doesn't impl equals (must it really impl hashCode?)
Hmm, do we need equals? Also, NodeHash relys on hashCode to judge whether two fst nodes can be 'merged'.
Oops, I forgot it still relys on equals to make sure two instance really matches, ok, I'll add that.
By the way, for real data, when two outputs are not 'NO_OUTPUT', even they contains the same metadata + stats,
it seems to be very seldom that their arcs can be identical on FST (increases less than 1MB for wikimedium1m if
equals always return false for non-singleton argument). Therefore... yes, hashCode() isn't necessary here.