[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13736504#comment-13736504
]
Yonik Seeley commented on SOLR-3076:
------------------------------------
The important parts of this issue are:
- Serialization formats (XML, javabin, etc)
- join semantics
- join syntax... i.e. \{!child ...} \{!parent ...}
- common public Solr Java APIs SolrInputDocument, UpdateHandler/UpdateProcessor
- correctness
Other things are implementation details that can be improved over time.
We should be aware of things we *don't* want to support long term... this
is why I removed the external/custom cache dependency (in addition to the
usability implications).
As far as "per-segment" goes, some of the previous patches had issues
(such as caching SolrCache in QParser instances), double-caching
(the filter used by the join would be cached separately from the
same filter used in all other contexts), the custom caches defined in
solrconfig.xml, not to mention my general dislike for weak references.
Since per-segment filter caching is an orthogonal issue (and it would be
best to be able to specify this on a per-filter basis), I decided it was
best to leave per-segment filters for a different issue and create queries
that would work well with the way Solr currently does it's filter caching
and request construction.
Additionally, how to deal with the "going backwards" problem / expecting
all filters to be FixedBitSet (which Solr doesn't use) is still up in the
air: LUCENE-5092. There's no reason to wait for that to get hashed out
before giving Solr users block child/parent join functionallity. Those details
of the Java APIs just don't matter to Solr users.
These query classes in question are package-private classes that Solr
users do not see - truly an implementation detail. Changing them in
the future (as long as the behavior is equivalent) would not even
warrant mention in release notes (unless performance had been improved).
Can there still be implementation improvements? Absolutely! But I'm
personally currently out of time on this issue, and I feel comfortable
with supporting the public APIs we've come up with for some time to come.
Since no one seems to have issues with any of the important parts like
the public APIs, I plan on committing this shortly. Additional
improvements/optimizations can come from follow-on patches.
> Solr(Cloud) should support block joins
> --------------------------------------
>
> Key: SOLR-3076
> URL: https://issues.apache.org/jira/browse/SOLR-3076
> Project: Solr
> Issue Type: New Feature
> Reporter: Grant Ingersoll
> Assignee: Yonik Seeley
> Fix For: 4.5, 5.0
>
> Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png,
> bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch,
> child-bjqparser.patch, dih-3076.patch, dih-config.xml,
> parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at
> 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch,
> SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
> SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
> SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
> SOLR-7036-childDocs-solr-fork-trunk-patched,
> solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch,
> tochild-bjq-filtered-search-fix.patch
>
>
> Lucene has the ability to do block joins, we should add it to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
