[
https://issues.apache.org/jira/browse/SOLR-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated SOLR-15213:
--------------------------------
Attachment: SOLR-15213-3.patch
Assignee: David Smiley
Status: Open (was: Open)
I'll take it from here; thanks. As an aside: I wish this was done as a PR as
it's clear what's changed in iterations and it's easier for me to show you what
I'm doing. But when you do want to use patch files, JIRA prefers that you keep
naming the file the same as it will keep track of the updates. I followed suit
here (-3) because this was already being done.
{quote}
I was reviewing how the id is read in AddUpdateCommand but it looks like it's
the same mechanism, converting it to string:
{quote}
Sometimes a String is needed, so that's why you found that. Ultimately a
BytesRef is most canonical. I made this change.
As for documentation, I plan to edit "[Adding a Child
Document|https://github.com/apache/solr/blob/a8290de0c1482a904012827ae2d7ae0e641e54a1/solr/solr-ref-guide/src/partial-document-updates.adoc#adding-a-child-document]";
at the end to add a clarifying note:
{quote}Note that this is add-or-replace (by ID). Meaning, if it happens that
doc `P11!S21` already has a child document with the ID `P11!D99` (the one we
are adding), then it will be replaced. Also, the document being added could
itself be an atomic update (e.g. to use "inc", "set", etc.). In that case, it
must be replacing an existing document so that it can apply the operation to
something.
{quote}
I'm not sure if anything needs to be said about single additions becoming
arrays, as it's kind of a minor bug fix. I'll say it in the commit message.
> Add support for "merge" atomic update operation for child documents
> -------------------------------------------------------------------
>
> Key: SOLR-15213
> URL: https://issues.apache.org/jira/browse/SOLR-15213
> Project: Solr
> Issue Type: New Feature
> Reporter: James Ashbourne
> Assignee: David Smiley
> Priority: Major
> Attachments: SOLR-15213-1.patch, SOLR-15213-2.patch,
> SOLR-15213-3.patch, SOLR-15213.patch
>
>
> Solr has "add", "set", "add-distinct" which work but all have their
> limitations. Namely, there's currently no way to atomically update a document
> where that document may or may not be present already by merging if it is
> present and inserting if it isn't.
> i.e. in the scenario where we have a document with two nested children:
>
> {noformat}
> {"id": "ocean1",
> "_isParent":"true",
> "fish": [
> {
> "id": "fish1",
> "type_s": "fish",
> "name_s": "Doe",
> "_isParent":"false"},
> {
> "id": "fish2",
> "type_s": "fish",
> "name_s": "Hans",
> "_isParent":"false"}]
> }{noformat}
>
> If we later want to update that child doc e.g.:
> {noformat}
> {"id": "ocean1",
> "_isParent":"true",
> "fish": [
> {
> "id": "fish1",
> "type_s": "fish",
> "name_s": "James", // new name
> "_isParent":"false"},
> ]
> }{noformat}
>
> Existing operations:
> - "add" - will add another nested doc with the same id leaving us with two
> children with the same id.
> - "set" - replaces the whole list of child docs with the single doc, we
> could use this but would first have to fetch all the existing children.
> - "add-distinct" - will reject the update based on the doc already being
> present.
> I've got some changes (see patch) that a new option "merge" which checks
> based on the id and merges the new document with the old with a fall back to
> add if there is no id match.
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
