[
https://issues.apache.org/jira/browse/SOLR-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295189#comment-13295189
]
Hoss Man commented on SOLR-3535:
--------------------------------
bq. Or simply allow SolrInputDocument as a normal value and existing APIs could
be used to add them. This would also be slightly more powerful, allowing more
than one child list for the same parent.
"allow SolrInputDocument as a normal value" ... a normal value to what? where?
... are you describing he same thing as Mikhail in modeling "children"
SolrInputDocuments as field values of the parent SOlrInputDOcument?
If so then i ask you the same questions i asked him above...
{quote}
bq. why new api/property is necessary? is solrInputDoc.addField("skus", new
Object[]\{sku1, sku2, sku3\}) not enough?
Are you suggesting we model child documents as objects (SolrInputDocuments i
guess?) in a special field? ... what if i put child documents in multiple
fields? would that signify the different types of child? how would solr model
that in the (lucene) Documents when giving them to the InddexWriter? How would
solr know how to order the children in from multiple fields/lists when creating
the block? Wouldn't the "type of child" information be better living in the
child documents itself? (particularly since that "type" information needs to be
in the child documents anyway so that the filter query for a BJQ can be
specified.)
It also seems like it would require code that wants to know what children exist
in a document to do a lot of work to find that out (need to iterate ever field
in the SolrInputDocument and do reflection to see if they are child-documents
or not)
Another concern off the top of my head is that a lot of existing code
(including any custom update processors people might have) would assume those
child documents are multivaluved field values and would probably break – hence
a new method on SolrInputDocument seems wiser (code that doens't know about may
not do what you want, but at least it won't break it)
{quote}
> Add block support for XMLLoader
> -------------------------------
>
> Key: SOLR-3535
> URL: https://issues.apache.org/jira/browse/SOLR-3535
> Project: Solr
> Issue Type: Sub-task
> Components: update
> Affects Versions: 4.1, 5.0
> Reporter: Mikhail Khludnev
> Priority: Minor
> Attachments: SOLR-3535.patch
>
>
> I'd like to add the following update xml message:
> <add-block>
> <doc>....</doc>
> <doc>....</doc>
> </add-block>
> out of scope for now:
> * other update formats
> * update log support (NRT), should not be a big deal
> * overwrite feature support for block updates - it's more complicated, I'll
> tell you why
> Alt
> * wdyt about adding attribute to the current tag {pre}<add block="true">{pre}
> * or we can establish RunBlockUpdateProcessor which treat every <add>
> ....</add> as a block.
> *Test is included!!*
> How you'd suggest to improve the patch?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
