Bingo. We do not have a field called "set", but we do have this line as
our final field definition:
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 i
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
wrote:
> I can reproduce the error on a fresh coll
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!
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
collect
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 collection
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 wo
