mikemccand commented on pull request #1733: URL: https://github.com/apache/lucene-solr/pull/1733#issuecomment-696781342
> So I propose we get rid of the fullPathField altogether. Wow, +1, this looks like it is (pre-existingly?) double-indexed? Maybe we should do this as a separate pre-cursor PR to this one (switch to `StoredField` when indexing the `fullPathField`)? > For maintaining backwards compatibility, we can read facet labels from new BinaryDocValues field, falling back to old StoredField if BinaryDocValues field does not exist or has no value for the docId. The performance penalty of doing so should be acceptable. Yeah +1 to, on a hit by hit basis, try `BinaryDocValues` first, and then fallback to the `StoredField`. This is the cost of backwards compatibility ... though, for a fully new (all `BinaryDocValues`) index, the performance should be fine. Also, note that in Lucene 10.x we can remove that back-compat fallback. > Alternatively we can implement a special merge policy that takes care of moving data from old Stored field to BinaryDocValues field at the time of merge but that might be tricky to implement. I think this would indeed be tricky. ---------------------------------------------------------------- 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. 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
