[
https://issues.apache.org/jira/browse/SOLR-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13295680#comment-13295680
]
Yonik Seeley commented on SOLR-3535:
------------------------------------
bq. If so then i ask you the same questions i asked him above...
We don't necessarily need to have all the answers today (about how modeling in
the index would work)... we just need to realize that we may want that extra
power / generality in the future. Don't think just in terms of BJQ - there
will be other ways to use the fact that we know a sequence of related docs are
contiguous.
bq. what if i put child documents in multiple fields?
This is what I think we should support to future-proof this.
bq. would that signify the different types of child?
Yes.
bq. how would solr model that in the (lucene) Documents when giving them to the
InddexWriter?
We could index a "type" field based on the field name (among other
possibilities including allowing the user to specify type).
bq. How would solr know how to order the children in from multiple fields/lists
when creating the block?
It hopefully shouldn't matter. child_list1, child_list2, parent
bq. 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.)
Yes, but it's not that clear to me how this is related to allowing documents as
field values.
bq. 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)
Yeah, this is what bothers me the most.
The code complexity part shouldn't be an issue - that can be wrapped up into a
utility class that visits all child documents. But I don't particularly like
the fact that we need to go through looking at every field value each time. On
the other hand, I also wouldn't like to duplicate the get/set API for child
documents on SolrInputDocument.
bq. 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
I don't think we should worry too much about custom update processors - it's
(IMO) more of an expert-level thing, this is 4.0, and most document mutating
processors I can think of probably also want to operate on child docs too.
Related: see SOLR-139
I used a Map to represent an "extended value" for a field, and then go through
and check for any of those to see if it's an "update" and what type it is.
It has the same downsides you describe above. The upsides were that everything
pretty much just worked w/o modification (update forwarding, javabin
serialization, etc).
> 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
