mikemccand commented on pull request #1733: URL: https://github.com/apache/lucene-solr/pull/1733#issuecomment-679097363
I think the back-compat layer at read-time is a good start, but is not quite enough. Imagine Susan. She upgrades to Lucene with this change, pushed, as it is now. Susan runs some queries against her index, resolves ordinals, using the stored fields, and all is good. Susan indexes some more documents with facet labels, and these new segments in the taxonomy index are written using `BinaryDocValues`. Susan refreshes and runs some queries, and some ordinals resolve using old way (if they came from old segments), and some the new way (if they came from new segments). Life goes on, more documents indexed. Suddenly, Susan's taxonomy index executes a merge! Merging old and new segments together, now the newly merged segment has a mix of some docs that used stored fields while others used `BinaryDocValues`, and the back compat logic will becomes confused and incorrectly try to use `BinaryDocValues` instead of stored fields, and I think that `assert` will trip for such documents? Could you try to add a test case showing this case? Have a look at Lucene's `TestBackwardsCompatibility` -- it tests the main index, but you can borrow the ideas (e.g. APIs to zip/unzip) to implement a new unit test confirming we are maintaining back-compat for taxonomy index? ---------------------------------------------------------------- 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
