We seem to get this error with an existing record in Solr
org.apache.solr.common.SolrException: Attempted an atomic/partial update to a child doc without indicating the _root_ somehow.
If I change the reference id to something that doesn't exist; it adds it fine and I can happily fire the same request in with no issue. I don't really understand this message and reading the solr documentation that also doesn't make sense!
Should it not just replace the whole document, thought it would be as simple as that, is the record corrupts maybe!?
How might I debug the issue in Solr or know what to look for?
Our solrconfig.xml had these defaults in, but unsure if this is what can cause this error.
<updateRequestProcessorChain name="add-unknown-fields-to-the-schema" default="${update.autoCreateFields:true}" processor="uuid,remove-blank,field-name-mutating,parse-boolean,parse-long,parse-double,parse-date,add-schema-fields">
<processor class="solr.LogUpdateProcessorFactory"/>
<processor class="solr.DistributedUpdateProcessorFactory"/>
<processor class="solr.RunUpdateProcessorFactory"/>
</updateRequestProcessorChain>
The url we seem to call is the following with the json object passed in
POST /solr/mycore/update?commit=true
I think these two links may have relevance, but all rather low level issues.
https://issues.apache.org/jira/browse/SOLR-15468
https://issues.apache.org/jira/browse/SOLR-14923
We don't store child objects, we only store single values or arrays of strings/numbers. We do also store the original JSON object string in the Bookings field, which has lots of extra stuff that we stripped out, this is a text_en field, so wondering if that's the issue; presume that is indexed which sounds dodgy as it can be quite a large object.
My current approach was to delete the record via the cores Document tab, then we could submit the request with no problems!
I do wonder if the issue stems from increasing a version from 7.6 to 8.11.1, but the person who copied the data just copied the data folder from 7.6 and put it in the 8.11.1 version, this seems rather dodgy and imagine a backup may have been a better idea.