Hi, I encountered a similar issue recently trying to differentiate between atomic and in-place updates. I ended up enabling debug logging for the DirectUpdateHandler2 class via Solr UI → Logging → Level options. Then the logs should print something like "DirectUpdateHandler2 updateDocValues" for an in-place update, or "DirectUpdateHandler2 updateDocument" for an atomic update.
Not sure if this applies to your setup, but in our case atomic updates were initially being used because we have a route.field defined and our Solr version did not yet have the fix for SOLR-13081 <https://issues.apache.org/jira/browse/SOLR-13081>. Matthew On Tue, Apr 5, 2022 at 2:39 PM gnandre <arnoldbron...@gmail.com> wrote: > 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 > > > > >
