lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Muir <>
Subject Re: revisit naming for grouping/join?
Date Fri, 01 Jul 2011 14:02:16 GMT
On Fri, Jul 1, 2011 at 8:51 AM, Michael McCandless
<> wrote:

> The join module does currently depend on the grouping module, but for
> a silly reason: just for the TopGroups, to represent the returned
> hits.  We could move TopGroups/GroupDocs into common (thus justifying
> its generic name!)?  Then both join and grouping modules depend on
> common.

Just a suggestion: maybe they belong in the lucene core? And maybe the
stuff in the common module belongs in lucene core's util package?

I guess I'm suggesting we try to keep our modules as flat as possible,
with as little dependencies as possible. I think we really already
have a 'common' module, thats the lucene core. If multiple modules end
up relying upon the same functionality, especially if its something
simple like an abstract class (Analyzer) or a utility thing (these
mutable integers, etc), then thats a good sign it belongs in core

I think we really need to try to nuke all these dependencies between
modules: its great to add them as a way to get refactoring started,
but ultimately we should try to clean up: because we don't want a
complex 'graph' of dependencies but instead something dead-simple. I
made a total mess with the analyzers module at first, i think
everything depended on it! but now we have nuked almost all
dependencies on this thing, except for where it makes sense to have
that concrete dependency (benchmark, demo, solr).

> I think what would be best is a smallish but feature complete demo, ie
> pull together some easy-to-understand sample content and the build a
> small demo app around it.  We could then show how to use grouping for
> field collapsing (and for other use cases), joining for nested docs
> (and for other use cases), etc.

For the same reason listed above, I think we should take our
contrib/demo and consolidate 'examples' across various places into
this demo module. The reason is:
* examples typically depend upon 'concrete' stuff, but in general core
stuff should work around interfaces/abstract classes: e.g. the
faceting module has an analyzers dependency only because of its
* examples might want to integrate modules, e.g. an example of how to
integrate faceting and grouping or something like that.
* examples are important: i think if the same question comes up on the
user list often, we should consider adding an example.

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

View raw message