It is configured as a unique field.
<uniqueKey>id</uniqueKey>
<field name="id" type="string" stored="true" indexed="true"/>
On Tue, Apr 5, 2022 at 4:10 PM Matthew Lapointe <mlapoi...@alpha-sense.com>
wrote:
> 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
> > > > >
> > > > >
> > > >
> > >
> >
>
