On 4/5/22 10:53, gnandre wrote:
Hi, here are the relevant fields from the schema.
<fieldType name="long" class="solr.LongPointField" docValues="true"/>
<field name="_version_" type="long" indexed="false" stored="false" docValues
="true" multiValued="false" />
<field name="views_count" type="long" stored="false" indexed="false"
docValues="true" multiValued="false"/>
There are no copyfields for views_count.
Here are the corresponding atomic indexing and commit requests:
curl http://solr:8983/solr/answers/update -d '[{"id" :
"answers:question:8029","views_count" : {"set":111}}]'
curl "http://solr:8983/solr/answers/update?commit=true";
Can you do some testing when there is no other indexing activity? What
I'd like to see is a long directory listing of the index directory
before an update like that, and then a long directory listing after an
update like that. To get the kind of listing I'm after, you would use
"ls -al" on a POSIX system like Linux, and "dir" in a command prompt on
windows.
It DOES change the value successfully. To verify if it is doing atomic
indexing or in-place update, I changed the name of one other field
from
<field name="asset_type" type="string" stored="true" indexed="true"
multiValued="true" default="1775"/>
to
<field name="asset_typ" type="string" stored="true" indexed="true"
multiValued="true" default="1775"/>
and reloaded the schema.
Now, when I send above mentioned atomic indexing request, I get following
error message:
{
"responseHeader":{
"status":400,
"QTime":7},
"error":{
"metadata":[
"error-class","org.apache.solr.common.SolrException",
"root-error-class","org.apache.solr.common.SolrException"],
"msg":"ERROR: [doc=answers:question:8029] unknown field 'asset_type'",
"code":400}}
So, I believe that it is still trying to index other fields as well from
their stored values and it is not an in-place update. What am I missing?
It is entirely possible that the code that does atomic or in place
updates checks the existing document against the current schema, and
throws that error even for in-place updates. I think it would have to
do that to figure out whether it CAN do an in-place update. I am not
sure which part of the source code I would even need to check to figure
that out. But if you can do the test above, I should be able to tell
you whether the update was fully atomic or in-place.
Thanks,
Shawn
