[
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: [email protected]
For additional commands, e-mail: [email protected]
