[ https://issues.apache.org/jira/browse/SOLR-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17726446#comment-17726446 ]
Alex Deparvu edited comment on SOLR-16799 at 5/30/23 5:52 PM: -------------------------------------------------------------- for some reason I am unable to understand the TestDistributedSearch test is failing because some field's value is getting placed under the 'keys' location of the response json. the JavaBinCodec tries to read the key as String and fails because it's actually a list of values. I kinda suspect this is related to the enum type (the field prior to this one that is failing), but not complete sure what is what yet. I might have narrowed it down to the EnumFieldType. I think it is persisted correctly (fieldsData as an array), but the reading of the field is not behaving. On main branch I see the Field coming back with fieldsData as Integer so the BinaryResponseWriter is able to jsonify it correctly. On my PR this field contains fieldsData as array, so `numericValue` comes back as null even though data is there (DocsStreamer#getValue -> AbstractEnumField#toExternal -> f.numericValue()). When the value comes back as null the writer will pass it on as null (BinaryResponseWriter#resolve) and the JavaBinCodec assumes the value was taken care of already and continues on to jsonify the rest of the query response. unfortunately this results in a broken json response, messing keys and values on the client side. Minor breakthrough. I think that due to this change https://github.com/apache/lucene/pull/12116 the way se setup EnumFieldType is no longer working correctly. we are only overriding `numericValue` to convey a numerical value type, but after the PR lucene will rely on `storedValue` as an optimization so we need to also override that method to return a numerical value, otherwise we end up with the raw fieldsData data and not an int value. this at least will get the TestDistributedSearch test to pass. the change itself will be posted in the PR for review. was (Author: alex.parvulescu): for some reason I am unable to understand the TestDistributedSearch test is failing because some field's value is getting placed under the 'keys' location of the response json. the JavaBinCodec tries to read the key as String and fails because it's actually a list of values. I kinda suspect this is related to the enum type (the field prior to this one that is failing), but not complete sure what is what yet. I might have narrowed it down to the EnumFieldType. I think it is persisted correctly (fieldsData as an array), but the reading of the field is not behaving. On main branch I see the Field coming back with fieldsData as Integer so the BinaryResponseWriter is able to jsonify it correctly. On my PR this field contains fieldsData as array, so `numericValue` comes back as null even though data is there (DocsStreamer#getValue -> AbstractEnumField#toExternal -> f.numericValue()). When the value comes back as null the writer will pass it on as null (BinaryResponseWriter#resolve) and the JavaBinCodec assumes the value was taken care of already and continues on to jsonify the rest of the query response. unfortunately this results in a broken json response, messing keys and values on the client side. > upgrade Solr to use Lucene 9.6.0 > -------------------------------- > > Key: SOLR-16799 > URL: https://issues.apache.org/jira/browse/SOLR-16799 > Project: Solr > Issue Type: Task > Reporter: Christine Poerschke > Priority: Major > Labels: newdev > > Apache Lucene 9.6.0 was recently released: > [https://lists.apache.org/thread/d4zw7o3t0g4h329wk7vc7s5730bsyk5t] > This ticket is to upgrade Solr's Lucene dependency from 9.5.0 to the latest > 9.6.0 version. > new or existing contributors interested in this ticket: > * please take a look at the documentation to see what's involved: > [https://github.com/apache/solr/blob/main/dev-docs/lucene-upgrade.md] > * optional: add a short note on this ticket to share your intention to work > on this > * make the upgrade changes (and of course do feel free to ask any questions > that may arise) > * open a pull request > Solr committers, please could you: > * help review/merge/backport etc. the pull request for this ticket > * try and leave the upgrade itself as an opportunity for someone else to > also contribute to the project > Thanks everyone! -- This message was sent by Atlassian Jira (v8.20.10#820010) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org