That's odd! The only other thing I can think to check would be to verify
that the "id" field is configured as the unique key field for the
collection.
Matthew
On Tue, Apr 5, 2022 at 3:43 PM gnandre <arnoldbron...@gmail.com> wrote:
> 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
> > > >
> > > >
> > >
> >
>
