[
https://issues.apache.org/jira/browse/SOLR-4774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13664662#comment-13664662
]
Hoss Man commented on SOLR-4774:
--------------------------------
There is probably a lot of good stuff in the lucene faceting module that could
be leveraged in Solr, but I think there are two extremelye important factors to
keep in mind before anyone tackles trying to integrate it with solr...
1) it's important to understand why/how the lucene faceting module came into
existence as an independent module instead of just wholesale refactoring the
existing Solr faceting code into a new directory.
namely the question of caching and how faceting code integrates with the schema.
As i commented in the thread which lead to the creation of the lucene faceting
module (LUCENE-3079)...
http://mail-archives.apache.org/mod_mbox/lucene-dev/201105.mbox/%3Calpine.DEB.2.00.1105061307200.5457@bester%3E
{quote}
To look at "faceting" as a concrete example, there are big the reasons faceting
works so well in Solr: Solr has total control over the index, knows exactly
when the index has changed to rebuild caches, has a strict schema so it can
make sense of field types and pick faceting algos accordingly, has multi-phase
distributed search approach to get exact counts efficiently across multiple
shards, etc... (and there are still a lot of additional enhancements and
improvements that can be made to take even more advantage of knowledge solr has
because it "owns" the index that we no one has had time to tackle)
I find it really hard to picture a way that this code could be refactored into
a reusable module in such a way that it could have an API that would be easily
usable outside of Solr -- and when i do get a glimmer of an inkling of what
that might look like, that vision scares me because of how that API might then
"hobble" Solr's ability to leverage it's total control of the underlying index
to add additional performance/features.
{quote}
2) Yonik hit the nail on the head in another thread (that i can't find now)
which asked about integrating lucene faceting in solr: it's important to think
about new Solr functionality from the perspective of the user, not just "here's
a lucene module that looks cool, lets drop it into solr."
The approach should be to say "by configuring W and then indexing documents X,
and specifying Y at request time, results Z should come out" and then the
values of W,X,Y and Z will help us understand what needs to be done under the
hood. That may be some simple glue code on top of the facet module, or it may
mean refactoring/enhancing the facet module APIs to let Solr inject info based
on the schema/request, or perhaps even some completely new algorithms that are
very Solr specific because of the data available, and distributed processing,
etc.... The focus needs to be on what the value add and API are for the users,
not what jars are used where
> Solr support Lucene Facets
> --------------------------
>
> Key: SOLR-4774
> URL: https://issues.apache.org/jira/browse/SOLR-4774
> Project: Solr
> Issue Type: New Feature
> Reporter: Bill Bell
>
> Since facets are now included in Lucene...
> 1. Solr schema taxonomy glue
> 2. Switch query results to use this glue with a new param like
> facet.lucene=true?
> Seems like a great enhancement !
--
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: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
