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

David Smiley commented on SOLR-12361:
-------------------------------------

bq. Do you propose we deprecate _childDocuments for the time being, leave it as 
is, while implementing child docs as values?  Later on(Solr 8.0) the 
_childDocuments will be removed?

Yes. 
(BTW I recommend sticking with using master branch for patch development / WIP; 
it shouldn't be an issue)

bq. Plus, would we have to enforce that no childDocument is inserted inside the 
childDocuments key annonymous childDocuments were inserted to the current doc?

That was my "XOR" posed as a question... I think we shouldn't bother to 
complicate ourselves with preventing it; so let it be possible.  In practice, I 
expect users to do one or the other.

RE DocumentBuilder:  Maybe nevermind my thoughts on changing that.  But I do 
think the changes to remove cmd.isBlock are worthwhile as it helps us remove 
`org.apache.solr.common.SolrDocumentBase#hasChildDocuments`

> Change _childDocuments to Map
> -----------------------------
>
>                 Key: SOLR-12361
>                 URL: https://issues.apache.org/jira/browse/SOLR-12361
>             Project: Solr
>          Issue Type: Sub-task
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: mosh
>            Priority: Major
>         Attachments: SOLR-12361.patch, SOLR-12361.patch
>
>          Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> During the discussion on SOLR-12298, there was a proposal to change 
> _childDocuments in SolrDocumentBase to a Map, to incorporate the relationship 
> between the parent and its child documents.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Reply via email to