Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
MIME-Version: 1.0
In-Reply-To: <1309526890.54413.YahooMailRC@web29020.mail.ird.yahoo.com>
References: <BANLkTi=rCXo-YC0z7=qxeEUBMMyn5YY6KQ@mail.gmail.com>
	<BANLkTimdWgt_YQb2ZcV=CBPk3iXm+cRY=g@mail.gmail.com>
	<1309526890.54413.YahooMailRC@web29020.mail.ird.yahoo.com>
Date: Sun, 3 Jul 2011 11:25:44 -0400
Message-ID: 
 <CAL8PwkZ44ToG2oevGjcobHvyk8+hLb_gESHOEzfSeEN=xcOXHg@mail.gmail.com>
Subject: Re: revisit naming for grouping/join?
From: Michael McCandless <lucene@mikemccandless.com>
To: dev@lucene.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 1, 2011 at 9:28 AM, mark harwood <markharw00d@yahoo.co.uk> wrot=
e:
>>> I think what would be best is a smallish but feature complete demo,
>
> For the nested stuff I had a reasonable demo on LUCENE-2454 that was base=
d
> around resumes - that use case has the one-to-many characteristics that l=
ends
> itself to nested e.g. a person has many different qualifications and reco=
rds of
> employment.
> This scenario was illustrated
> here: http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-=
support-in-lucene
>
> I also had the "book search" type scenario where a book has many sections=
 and
> for the purposes of efficient highlighting/summarisation =A0these section=
s were
> treated as child docs which could be read quickly (rather than highlighti=
ng a
> whole book)

I think both resumes and book search, and also others like the
variants of a product SKU, would all make good examples for the nested
docs use case.

> I'm not sure what the "parent" was in your doctor and cities example, Mik=
e. If a
> doctor is in only one city then there is no point making city a child doc=
 as the
> one city info can happily be combined with the doctor info into a single
> document with no conflict (doctors have different properties to cities).
> If the city is the parent with many child doctor docs that makes more sen=
se but
> feels like a less likely use case e.g. "find me a city with doctor x and =
a
> different doctor y"
> Searching for a person with excellent java and prefrerably good lucene sk=
ills
> feels like a more real-world example.

In my example the city was parent -- I raised this example to explain
that index-time joining is more general than just nested docs (ie, I
think we should keep the name "join" for this module... also because
we should factor out more general search-time-only join capabilities
into it).

> It feels like documenting some of the trade-offs behind index design choi=
ces is
> useful too e.g. nesting is not too great for very volatile content with
> constantly changing children while search-time join is more costly in RAM=
 and
> 2-pass processing

+1, especially once we've factored out generic joins.

Mike

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org