You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@lucene.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2021/01/08 04:42:00 UTC

[jira] [Issue Comment Deleted] (SOLR-15064) Atomic/partial updates to nested docs should not assume _route_ param is the root ID

     [ https://issues.apache.org/jira/browse/SOLR-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Smiley updated SOLR-15064:
--------------------------------
    Comment: was deleted

(was: Commit 4cb3ad4a1c40b4326aec64577a7e60018f7f1a5e in lucene-solr's branch refs/heads/master from David Smiley
[ https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=4cb3ad4 ]

* SOLR-14923: Nested docs indexing perf & robustness (#2159)

* When the schema defines _root_, and you want to do atomic/partial updates...
** _root_ needn't be stored or have docValues any more
** _nest_path_ field isn't needed for this any more
** Simplified internal logic
* Allow (and recommend, eventually insist) that the _root_ field be passed for atomic/partial updates to child docs.
** In the absence of _root_, assume the _route_ param is equivalent to ameliorate back-compat scope.  This is a temporary hack; remove in SOLR-15064.
** One of the two is required; you'll get an exception if the assumption is false.  THIS IS A BACK-COMPAT CHANGE
* Ensure that the update log contains the _root_ field if it's defined in the schema; in some cases it wasn't.  It's important for robustness of atomic/partial updates to child docs.  Caveat: the buffer replay scenario is not tested with child docs.
* Limited the cases when a realtime searcher is re-opened.  It was being applied to any update that included child docs but now only some narrow subset: only for atomic/partial updates, and when the update log contains an in-place update for the same nest because it's complicated to resolve those log entries.
* Internal improvements to RealTimeGetComponent to aid clarity & robustness & probably performance...
** Use SolrDocumentFetcher.solrDoc(docID, ReturnFields) instead of more manual loading.  Will do more with this in another PR.
** Clarify when only root doc IDs are expected.
** Use Resolution enum more, add PARTIAL, remove DOC_WITH_CHILDREN; enhance docs.
** When have ReturnFields, a Set of "onlyTheseFields" becomes redundant.  Add a child doc resolution via a transformer when needed.
** Clarified where copy-field targets are removed
* NestPathField should default to single valued, instead of inheriting the schema default, which for ancient schemas was multi-valued.
* AddUpdateCommand.getLuceneDocument(s) methods are very internal; made package visible and refactored a bit for clarity
* DocumentBuilder: when in-place update, skip id and _root_ here, thus also simplifying further logic
* NestedShardedAtomicUpdateTest no longer extends AbstractFullDistribZkTestBase because it wasn't really leveraging the "control client" checking, and it added too much complexity to debug failures.)

> Atomic/partial updates to nested docs should not assume _route_ param is the root ID
> ------------------------------------------------------------------------------------
>
>                 Key: SOLR-15064
>                 URL: https://issues.apache.org/jira/browse/SOLR-15064
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: David Smiley
>            Assignee: David Smiley
>            Priority: Minor
>              Labels: NestedDocuments
>
> In SOLR-14923, doing an atomic/partial update to a child doc requires indicating what the root doc ID is.  Formerly Solr tried to figure this out automatically, but that had costly implications.   SOLR-14923 adds a temporary hack that assumes that the \_route_ paramter *is* the root ID, if the \_root_ field is not on the doc.  But that's not necessarily accurate, so it should be removed.
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org