[jira] [Comment Edited] (SOLR-12638) Support atomic updates of nested/child documents for nested-enabled schema

["mosh (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16616719#comment-16616719 ] 

mosh edited comment on SOLR-12638 at 9/16/18 1:24 PM:
------------------------------------------------------

This patch contains a fix for the process of deleting the old version of the newly updated block from the collection, when an atomic update for a block occurs.
Beforehand, DeleteUpdateCommand#setVersion was called when initializing the deleteRequest for said block, which would also delete the newly updated block from the collection.
This was cause since DeleteUpdateCommand#setVersion appends `_version_:[v TO *]` (where v is the set version) to the delete query.
{quote}I uploaded a no commit patch, in which triggering a DistrubutedUpdateProcessor#versionDeleteByQuery seems to trigger a commit
{quote}
The whole block is not retrieved by /get handler after an update, since DistributedUpdateHandler#versionDeleteByQuery (which is used to delete the old block) triggers UpdateLog#openRealtimeSearcher. This method clears all the caches, where the whole block was previously cached. That is why the whole block is not returned, since it is no longer cached. To get the whole block ChildDocTransformer is now called in AtomicUpdateBlockTest#testBlockRealTimeGet /get requests. ex:
{code:java}
assertJQ(req("qt","/get", "id","1", "fl","id, cat_ss, child1, [child]")
     ,"=={\"doc\":{'id':\"1\"" +
     ", cat_ss:[\"aaa\",\"ccc\",\"bbb\"], child1:{\"id\":\"2\",\"cat_ss\":[\"child\"]}" +
     "       }}"
     );{code}


was (Author: moshebla):
This patch contains a fix for the process of deleting the old version of the newly updated block from the collection, when an atomic update for a block occurs. Beforehand, DeleteUpdateCommand#setVersion was called when initializing the deleteRequest for said block, which would also delete the newly updated block from the collection. The cause for this is that the #setVersion method appends _version_:[v TO *] (where v is the set version) to the query of the delete request.
{quote}I uploaded a no commit patch, in which triggering a DistrubutedUpdateProcessor#versionDeleteByQuery seems to trigger a commit
{quote}
The whole block is not retrieved by /get handler after an update, since a DistributedUpdateHandler#versionDeleteByQuery (used to delete the old block) triggers UpdateLog#openRealtimeSearcher, which clears all the caches, where the whole block was once cached. That is why the whole block is not returned, since it is not available in cache, and now the childdoctransformer is added to the fl param in AtomicUpdateBlockTest#testBlockRealTimeGet /get requests. ex:
{code:java}
assertJQ(req("qt","/get", "id","1", "fl","id, cat_ss, child1, [child]")
     ,"=={\"doc\":{'id':\"1\"" +
     ", cat_ss:[\"aaa\",\"ccc\",\"bbb\"], child1:{\"id\":\"2\",\"cat_ss\":[\"child\"]}" +
     "       }}"
     );{code}

> 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
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org