: Also... I think we are over-thinking the name ;) We can't convey : *everything* in this name; as long as the name makes it clear that : you'll want to consider this / read its javadocs whenever doing : something with "nested docs", I think that's sufficient. I think : NestedQueryWrapper (maybe NestedDocsQuery) and NestedDocsCollector are : good enough, at least better than the functional-driven names they now : have...
Yeah, that's fair ... i'm not in love with NestedDocsQuery and NestedDocsCollector but i agree they are better then what we have now. : Honestly at this point I'm tempted to just stick with what we have : (the functionally driven names, instead of the dominant use case : driven name). : : At its heart, this query is performing a join (well, finishing the : join that was done during indexing), and despite our efforts to more : descriptively capture the dominant use case, I don't think we're : succeeding. We are basically struggling to find ways to explain what : a join does, into these class names. I really think it's a bad idea to use "Join" in the name ... i understand that to you this is a "join", but as you say it's really just finishing a join that was already done at index time -- for most users "join" is going to have the connotation of a SQL join where you don't have to normalize the data in advance (ie: build the index with all the docs you want ot join in a block) and we shouldn't use it unless we are talking about a truely generic query time join -- particularly if we are going to use examples i nthe doc that seem like the kind of think you would do with a query time join in SQL. i know you feel like "nested" (or "subdocs" or "parent") undersells the *possible* usecases of this feature, but the thing to remember is that even in the use cases where the real life data isn't something you might think of as being organized in a "nested" or "hierarchical" model, in order to use this feature the user must map their source data model to a Lucene Document model that *does* capture a hierarchy relationship so they can index their data in in the appropraite way. X and Y may not be in a hierarchy, but if you want to join them like this, then the Document for X and the Document for Y must be thought of as being in a hierarchy and indexed in lock step with eachother. "Block" just doesn't feel like it really conveys this ... but anything along the "Nested", "Parent", "Subdoc", line of terminology would at least give some point of refrence to the idea that the *Document* model in Lucene needs to be organized in this way -- and i think it's really important that the name make that clear. -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
