On Mon, Dec 17, 2012 at 4:02 PM, Shai Erera <ser...@gmail.com> wrote: > How do these two go together? > >> I think for DOCS_ONLY it makes sense that we lie (say freq=1 when we >> don't know): lots of places would otherwise have to be special cased >> for when they consume DOCS_ONLY vs DOCS_AND_POSITIONS. > > > and > >> I'm also not sure that >> all codecs return 1 today if the fields was indexed with DOCS_ONLY ... > > > That just makes it even worse right? I.e., we have code today that relies > no that behavior, but we're not sure it works w/ all Codecs?
Sorry, for my last sentence above I think I meant "I'm also not sure that all codecs return 1 today if you ask for FLAG_NONE". > Remember that DocIdSetIterator.nextDoc() was loosely specified? It was very > hard to write a decent DISI consumer. Sometimes calling nextDoc() returned > MAX_VAL, sometimes -1, sometimes who knows. When we hardened the spec, it > actually made consumers' life easier, I think? Right, locking down the API makes total sense in general. > It's ok if we say that for DOCS_ONLY you have to return 1. That's even 99.9% > of the time the correct value to return (unless someone adds e.g. the same > StringField twice to the document). Right. > And it's also ok to say that if you passed FLAG_NONE, freq()'s value is > unspecified. I think it would be wrong to "lie" here .. not sure if the > consumer always knows how DocsEnum was requested. Not sure if this happens > in real life though (consuming a DocsEnum that you didn't obtain yourself), > so I'm willing to ignore that case. +1: I think FLAG_NONE should remain undefined. I think we have codecs today that will return 1, 0, the actual doc freq (when the field was indexed as >= DOCS_AND_FREQS). > These two together sound like a reasonable "spec" to me? +1 So I think just change your javadocs patch to say that FLAG_NONE means freq is not defined, and if field was indexed as DOCS_ONLY and you asked for FLAG_FREQS then we promise to lie and say freq=1? Mike McCandless http://blog.mikemccandless.com --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
