Thanks, Shawn. I conducted the test that you mentioned.
Here is the diff - https://www.diffchecker.com/sdsMiGW5 Left hand side is the state before the in-place update. Right hand side is the state after the in-place update. On Tue, Apr 5, 2022 at 1:05 PM Shawn Heisey <elyog...@elyograg.org> wrote: > 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 > >
