lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hoss Man (JIRA)" <>
Subject [jira] [Commented] (SOLR-3535) Add block support for XMLLoader
Date Thu, 14 Jun 2012 17:48:43 GMT


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...

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)
> Add block support for XMLLoader
> -------------------------------
>                 Key: SOLR-3535
>                 URL:
>             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
> 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:!default.jspa
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message