[
https://issues.apache.org/jira/browse/SOLR-12638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16872898#comment-16872898
]
David Smiley commented on SOLR-12638:
-------------------------------------
What gnaws at me is that this "UpdateLog.openRealtimeSearcher" is being called
optimistically on a new doc because _maaaayyyybeee_ some future atomic update
will need to see it. And not just any type of atomic update; one that is
directly to a nested child doc. It's as if we're optimizing for making that
future atomic update faster by doing work in advance that will, I think, very
rarely actually be used. It's a tragedy, if I'm understanding this right. If
I do... then perhaps instead we somehow flag the UpdateLog to tell it that it's
realtime searcher is "dirty" so it needs a new one _if_ it's asked for one.
Just an idea off the top of my head.
> 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
> Reporter: mosh
> Assignee: David Smiley
> Priority: Major
> Fix For: 8.1
>
> Attachments: SOLR-12638-delete-old-block-no-commit.patch,
> SOLR-12638-nocommit.patch, SOLR-12638.patch, SOLR-12638.patch
>
> Time Spent: 17h 10m
> 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]
