Bingo. We do not have a field called "set", but we do have this line as our final field definition:
<dynamicField name="*" type="ignored" /> So it must have been simply ignoring the "set". I removed that line just to test it, created a new collection, indexed a single document, and was able to do the atomic update. Thanks for the insight! On Tue, Jul 2, 2024 at 3:19 PM Calvin Smith <calvin.sm...@lucasfilm.com> wrote: > Hi Jeremy, > > If the collection you're having the problem with has a schema with a field > named 'set', you might be running into > https://issues.apache.org/jira/browse/SOLR-17274. > > Cheers, > Calvin > > On Mon, Jul 1, 2024 at 3:39 PM Jeremy Buckley - IQS-C > <jeremy.buck...@gsa.gov.invalid> wrote: > > > I can reproduce the error on a fresh collection with only a single > document > > added, so it may be something related to my schema. > > > > I think at this point I'm about ready to punt and just do non-atomic full > > updates for this scenario, which actually won't be that difficult. > > > > Thanks for your suggestions! > > > > On Mon, Jul 1, 2024 at 2:58 PM Christos Malliaridis < > > c.malliari...@gmail.com> > > wrote: > > > > > With a correctly configured configset and a collection with data in > it, I > > > can only reproduce the error if there are documents that are wrongly > > > indexed. In that situation, fixing the documents in the collection (so > > that > > > they are no flattened documents) and reloading / reindexing the > affected > > > collections may solve the issue. I don't think it's an issue directly > > > related to the version of Solr. It sounds like an issue with the > > documents > > > that may have been reindexed during the upgrade process and identified > an > > > inconsistency that previously was ignored or skipped. > > > > > > What I would do in this case is: > > > - Make sure there are no invalid documents (with wrong fields or > values) > > in > > > your collection > > > - Try fully reindex your documents (see here > > > < > > > > > > https://solr.apache.org/guide/solr/latest/upgrade-notes/major-changes-in-solr-9.html#reindexing-after-upgrade > > > > > > > ) > > > - Make sure all your clients run on a compatible (preferably the same) > > > version with your Solr deployment > > > > > > The issue may also not be caused by the price_list_url, but instead by > > some > > > other field (or even document) that is identified as a nested object. > > > > > > If you can provide a simplified reproducer, it will be easier to > suggest > > > working solutions. > > > > > > On Mon, Jul 1, 2024 at 5:58 PM Jeremy Buckley - IQS-C > > > <jeremy.buck...@gsa.gov.invalid> wrote: > > > > > > > Hi Christos, thanks for the reply. I am using the /update endpoint. > > If I > > > > change to /update/json/docs, it does what you suggest and creates a > > > > flattened document. But that isn't what I want. > > > > > > > > Somewhat strangely, I only have one collection that is acting this > way > > - > > > > atomic updates on other collections are working fine. Also, > everything > > > > worked as expected under Solr 8.11.2 and before. > > > > > > > > On Mon, Jul 1, 2024 at 10:29 AM Christos Malliaridis < > > > > c.malliari...@gmail.com> wrote: > > > > > > > > > Hi Jeremy, > > > > > > > > > > Based on the information you provided I would say that your > > > > price_list_url > > > > > is recognized as an object instead of a field update. Depending on > > the > > > > way > > > > > you update your document(s), this may succeed and do what you want, > > > > succeed > > > > > and create flattened documents or fail. A flattened object would > look > > > > like > > > > > this in your case: > > > > > { > > > > > "id":"contracts 36F79718D0274 | 65 II I", > > > > > " price_list_url.set":["https://prices.anywhere.com";], > > > > > "_version_":1803386312791687168 > > > > > } > > > > > > > > > > How exactly are you updating your documents? What endpoint are you > > > using > > > > > and which request handler is processing your request? One potential > > > root > > > > > cause I can think of is mixing the endpoints /update/json/docs and > > > > /update. > > > > > > > > > > Sincerely, > > > > > Christos > > > > > > > > > > On Sun, Jun 30, 2024 at 8:50 PM Jeremy Buckley - IQS-C > > > > > <jeremy.buck...@gsa.gov.invalid> wrote: > > > > > > > > > > > After updating to 9.6.1, the following update is failing: > > > > > > > > > > > > [{ > > > > > > "id":"contracts 36F79718D0274 | 65 II C", > > > > > > "price_list_url" : { "set" : "https://prices.anywhere.com"; } > > > > > > }] > > > > > > > > > > > > Solr responds with: > > > > > > > > > > > > { > > > > > > "responseHeader": { > > > > > > "rf": 1, > > > > > > "status": 400, > > > > > > "QTime": 4 > > > > > > }, > > > > > > "error": { > > > > > > "metadata": [ > > > > > > "error-class", > > > > > > "org.apache.solr.common.SolrException", > > > > > > "root-error-class", > > > > > > "org.apache.solr.common.SolrException" > > > > > > ], > > > > > > "msg": "Unable to index docs with children: the schema > must > > > > > include > > > > > > definitions for both a uniqueKey field and the '_root_' field, > > using > > > > the > > > > > > exact same fieldType", > > > > > > "code": 400 > > > > > > } > > > > > > } > > > > > > > > > > > > We do not have nested child documents, at least not > intentionally. > > > > Schema > > > > > > has: > > > > > > > > > > > > <field name="id" type="string" indexed="true" multiValued="false" > > > > > > omitNorms="true" omitPositions="true" > > omitTermFreqAndPositions="true" > > > > > > stored="true" termVectors="false"/> > > > > > > ... > > > > > > <field name="price_list_url" type="string" indexed="true" > > > stored="true" > > > > > > multiValued="false" /> > > > > > > ... > > > > > > <uniqueKey>id</uniqueKey> > > > > > > > > > > > > There is no _root_ field defined in the schema, and it is > > > > > > using ClassicIndexSchemaFactory. > > > > > > We are running Solr Cloud, this collection has one shard and two > > > > > replicas. > > > > > > > > > > > > Any ideas what could be causing this error or how to fix it? > > > > > > > > > > > > Thanks in advance! > > > > > > > > > > > > > > > > > > > -- > > Jeremy Buckley > > Principal Software Applications Engineer > > > > Halley’s COMET Contract | Octo, an IBM Company > > Mobile: 703-626-6107 > > Email: jeremy.buck...@gsa.gov > > > -- Jeremy Buckley Principal Software Applications Engineer Halley’s COMET Contract | Octo, an IBM Company Mobile: 703-626-6107 Email: jeremy.buck...@gsa.gov
