Hi, So to be clear - you have a working fix by adding the _root_ field to your schema?
I suppose most 8.x users already have a _root_ field, so the thing you are seeing could very well be some bug related to atomic update. Can I propose that you create a minimal reproduction of this issue and upload somewhere? It could e.g. be a set of curl commands that, starting from a newly installed Solr 8.11 (or even better 9.1) reproduce the issue. Hint: You can create a collection with default schema: `solr create -c test` and then remove the _root_ field by issuing a delete-field command as described here https://solr.apache.org/guide/solr/latest/indexing-guide/schema-api.html#delete-a-field Jan > 8. des. 2022 kl. 15:30 skrev Eduardo Gomez <ego...@mintel.com.INVALID>: > >> At first it wasn't clear to me what the problem you're having actually >> is. Then I glanced back at the message subject ... it is the only place >> you mention it. > > Sorry Shawn, you are right, I didn't explain very clearly. So basically, in > Solr 8.11.1, I can see that updating an existing document, e.g. {"id": > "22468d41-3b...", "title": "Old title"}: > > curl -X POST -H 'Content-type:application/json' ' > http://localhost:8983/solr/clients_main/update?commit=true' --data "{'add': > {'doc':{'id': '22468d41-3b...', 'title': 'New title'}}}" > > I get two docs with the same id and different titles in the index. That is > different to the behaviour I see using Solr 7.5, which is a single document > with the updated title.To get that with the same schema in Solr 8.11.1, I > have to add this to the schema: > > <field name="_root_" type="string" indexed="true" stored="false"> > > So without the _root_ definition, the behaviour is as expected in Solr 7.5 > but produces duplicate documents in Solr 8.11. I haven't noticed Solr > complainig if the _root_ field is not defined. > > So my question was if that is expected, as that field seems to be related > to parent-child documents, which I don't use at all. > > The definition for the id field in my schema.xml is similar to the one you > posted: > > <fieldType name="string" class="solr.StrField" sortMissingLast="true"/> > <field name="id" type="string" indexed="true" stored="true" required="true" > docValues="false"/> > <uniqueKey>id</uniqueKey> > > Eduardo > > > > > > > On Thu, Dec 8, 2022 at 1:11 PM Mikhail Khludnev <m...@apache.org> wrote: > >> Right, Shawn. That's how it works >> >> https://lucene.apache.org/core/7_4_0/core/org/apache/lucene/index/IndexWriter.html#updateDocuments-org.apache.lucene.index.Term-java.lang.Iterable- >> And it's really fast in query time. >> >> On Thu, Dec 8, 2022 at 4:06 PM Shawn Heisey <apa...@elyograg.org> wrote: >> >>> On 12/8/22 05:58, Shawn Heisey wrote: >>>> So you can't just update a child document, you have to update all the >>>> children and all the parents at the same time, so the new documents >>>> are all in the same segment. >>> >>> That's a little unclear and sounds like a draconian requirement. :) I >>> meant that all children must be in the same segment as their parent. I >>> think Solr might support the idea of multiple nesting levels ... if so, >>> then the ultimate parent document and all its descendants need to be in >>> the same segment. >>> >>> Thanks, >>> Shawn >>> >>> >> >> -- >> Sincerely yours >> Mikhail Khludnev >> > > -- > > Mintel Group Ltd | Mintel House, 4 Playhouse Yard | London | EC4V 5EX > Registered in England: Number 1475918. | VAT Number: GB 232 9342 72 > > Contact details for our other offices can be found at > http://www.mintel.com/office-locations > <http://www.mintel.com/office-locations>. > > This email and any attachments > may include content that is confidential, privileged > or otherwise > protected under applicable law. Unauthorised disclosure, copying, > distribution > or use of the contents is prohibited and may be unlawful. If > you have received this email in error, > including without appropriate > authorisation, then please reply to the sender about the error > and delete > this email and any attachments. >
