lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael McCandless <>
Subject Re: revisit naming for grouping/join?
Date Sun, 03 Jul 2011 15:20:45 GMT
On Fri, Jul 1, 2011 at 10:02 AM, Robert Muir <> wrote:
> 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?


If we can generalize TopDocs so that we parameterize the type of each
hit, ie it could be a leaf (single doc + score (ScoreDoc) + maybe
field values (FieldDoc)) or another TopDocs, then we don't need the
separate TopGroups anymore.

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

I like this approach.

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


I think especially now that we have very new "interesting" modules
(facet, join, grouping), we really need corresponding examples to
showcase all of this.


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

View raw message