On Fri, Jul 1, 2011 at 10:02 AM, Robert Muir <rcm...@gmail.com> wrote: > On Fri, Jul 1, 2011 at 8:51 AM, Michael McCandless > <luc...@mikemccandless.com> 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?
+1 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). Good! >> 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. +1 I think especially now that we have very new "interesting" modules (facet, join, grouping), we really need corresponding examples to showcase all of this. Mike --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
