[
https://issues.apache.org/jira/browse/SOLR-18197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18120890#comment-18120890
]
Chris M. Hostetter commented on SOLR-18197:
-------------------------------------------
The commits made for this Jira changed the inheritance of {{NestPathField}}
from {{SortableTextField}} to {{StrField}} such that users attempting to
upgrade may get weird schema errors if they have previously used the schema API
in anyway to modify the schema (even if they have never used or modified any
{{NestPathField}} related fields/fieldtypes)
steps to reproduce...
{noformat}
# leave this running in one terminal
docker run -p 8983:8983 -p 9983:9983 --network host --rm -it solr:9.10
solr-foreground -c -DzkRun
# in another terminal...
curl
"http://localhost:8983/solr/admin/collections?action=CREATE&name=my_collection&numShards=1&replicationFactor=1";
curl -X POST -H 'Content-type:application/json' --data-binary
'{"add-field":{"name":"test","type":"string"}}'
'http://localhost:8983/solr/my_collection/schema'
{noformat}
Now use the Admin UI to inspect the managed-schema.xml for this collection in
ZK, and note the way the Schema API rewrote the {{NestPathField}} to include
{{SortableTextField}} that were previously hardcoded in the {{NestPathField}}
code...
{noformat}
<fieldType name="_nest_path_" class="solr.NestPathField"
omitTermFreqAndPositions="true" omitNorms="true" maxCharsForDocValues="-1"
multiValued="false" stored="false"/>
{noformat}
...if you now attempt to upgrade to the Solr 9.11-RC release candidate, the new
impl of {{NestPathField}} and you will gen an error.
This is most easily demonstrated by trying to attach a 9.11-RC node to the
existing zk, and adding a replica on the new node...
{noformat}
# with previous solr node still running, run this in a new terminal and leave
it running...
docker run -it --rm --network host -p 8985:8985 -e SOLR_PORT=8985
apache/solr:9.11.0-SNAPSHOT solr-foreground -c -z localhost:9983
# use admin ui to confirm 2 nodes are now part of the cluster:
http://localhost:8983/solr/#/~cloud?view=nodes
# in a new terminal, try to add a replica of our existing collection to the
"new" 9.11 node
curl
'http://localhost:8983/solr/admin/collections?action=ADDREPLICA&collection=my_collection&shard=shard1&node=127.0.1.1:8985_solr'
{noformat}
You should see this fail with errors like his in the log...
{noformat}
2026-09-29 20:20:09.601 ERROR (qtp485845532-19-null-46) [ t:null-46]
o.a.s.h.RequestHandlerBase Client exception
=>org.apache.solr.common.SolrException: Error CREATEing SolrCore
'my_collection_shard1_replica_n3': Unable to create core
[my_collection_shard1_replica_n3] Caused by: schema fieldtype
_nest_path_(org.apache.solr.schema.NestPathField) invalid
arguments:{maxCharsForDocValues=-1}
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1677)
{noformat}
> Query _nest_path_ (NestPathField) ease-of-use
> ---------------------------------------------
>
> Key: SOLR-18197
> URL: https://issues.apache.org/jira/browse/SOLR-18197
> Project: Solr
> Issue Type: Improvement
> Components: search
> Reporter: David Smiley
> Priority: Major
> Labels: newdev, pull-request-available
> Fix For: 9.11
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> The {{\_nest\_path\_}} / {{NestPathField}} could use some ease-of-use
> affordances, particularly for when searching for root documents. Thanks to
> the ways that the FieldType gets plugged into query parsers (especially
> FieldType.getFieldQuery), we should be able to override that method so that
> we support the following query:
> {noformat}
> {!field f=_nest_path_ v=/}{noformat}
> As equivalent to today:
> {noformat}
> (*:* -{!prefix f=_nest_path_ v=/}){noformat}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
