Thanks, Matthew.
I tried debugging as you suggested. It seems that it is still doing atomic
update instead of in-place update.
I am not using SolrCloud, so I don't think that SOLR-13081 is applicable in
my situation. I am using Solr 8.5.2 in standalone mode.
I am not sure why in-place updates are still not getting triggered :(
solr_1 | 2022-04-05 19:37:22.453 DEBUG
(qtp825658265-16) [ x:answers] o.a.s.u.DirectUpdateHandler2
updateDocument(add{_version_=1729298371656548352,id=answers:question:8029})
On Tue, Apr 5, 2022 at 3:10 PM Matthew Lapointe <mlapoi...@alpha-sense.com>
wrote:
> 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
> > >
> > >
> >
>
