[
https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16658534#comment-16658534
]
David Smiley commented on SOLR-12638:
-------------------------------------
I think it's very sketchy for Solr to do either (1) or (2). I think the user
should (somehow) provide the root ID, which would only modify your example
slightly. Thus this is (3)? One option is to provide the {{\_root\_}} field
in the document being updated. The only thing I don't like about this is that
this would be the very first time that a user has to actually use this field in
any way; normally the field is an internal implementation detail. Granted we
don't hide the detail at all, so it's not a leap to ask the user to use this in
this advanced case. Or, perhaps we insist the user send a {{\_route\_}}
parameter to /update which is otherwise only used in searches?
BTW your last paragraph... IMO we don't have a problem with URP ordering (IMO).
It's already quite wrong to order DURP after RUP. My concern loosely
expressed in my previous comment is broadly about UpdateLog integration.
> Support atomic updates of nested/child documents for nested-enabled schema
> --------------------------------------------------------------------------
>
> Key: SOLR-12638
> URL: https://issues.apache.org/jira/browse/SOLR-12638
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: mosh
> Priority: Major
> Attachments: SOLR-12638-delete-old-block-no-commit.patch,
> SOLR-12638-nocommit.patch
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> I have been toying with the thought of using this transformer in conjunction
> with NestedUpdateProcessor and AtomicUpdate to allow SOLR to completely
> re-index the entire nested structure. This is just a thought, I am still
> thinking about implementation details. Hopefully I will be able to post a
> more concrete proposal soon.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
