David,
The standard one-to-many solution is indexing each address (the many) as its
own document, and then either copy the other fields from your current schema to
these documents, or index using a heterogeneous field schema, grouping the
different doc type instances with a unique key (the one) to form a composite
doc. (These solutions address your discomfort with a single address field.)
Also, while you say that you don't have a hierarchy, I think you do; what you
have described could be expressed in XML as:
<doc>
<field1>...</field1>
...
<addresses>
<address id="1">
<street>...</street>
<city>...</city>
<state>...</state>
<zip>...</zip>
</address
<address id="2">
<street>...</street>
<city>...</city>
<state>...</state>
<zip>...</zip>
</address>
...
</addresses>
</doc>
I believe you could use the scheme I described on the other thread, using a
single address field, if you encoded it like so:
_ADDRESS_ _STREET_ 12 Main Street _CITY_ Metripilos _STATE_ MZ _ZIP_ 00000
_ADDRESS_ _STREET_ 512 23rd Avenue _CITY_ Carmtwon _STATE_ XB _ZIP_ 00001
...
Then to find the docs associated with Carmtwon, XB:
<SpanNot>
<Include>
<SpanOr>
<SpanNear slop="2147483647" inOrder="true">
<SpanTerm>_CITY_</SpanTerm>
<SpanTerm>Carmtwon</SpanTerm>
<SpanTerm>_STATE_</SpanTerm>
<SpanTerm>XB</SpanTerm>
</SpanNear>
<SpanOr>
</Include>
<Exclude>
<SpanTerm>_ADDRESS_</SpanTerm>
</Exclude>
</SpanNot>
Steve
On 03/29/2010 at 9:11 AM, David Smiley (@MITRE.org) wrote:
>
> Sorry, I intended to design my post so that one wouldn't have to read
> the thread for context but it seems I failed to do that. Don't bother
> reading the thread. The use-case I'm pondering modifying Lucene/Solr to
> solve is the one-to-many problem. Imagine a document that contains
> multiple addresses where each field of an address (like street, state,
> zipcode) go in different multi-valued fields. The main difficulty is
> considering how Lucene might be modified to have query results across
> different fields be intersected by a matching term position offset
> (which is designed in these fields to refer to a known value offset).
>
> Following the link you gave is interesting though the general case I'm
> talking about doesn't have a hierarchy. And I find the use of a single
> multi-valued field unpalatable for a variety of reasons.
>
> ~ David Smiley
>
> -----
> Author: https://www.packtpub.com/solr-1-4-enterprise-search-
> server/book -- View this message in context:
> http://n3.nabble.com/One-item-multiple-
> fields-and-range-queries-tp475030p683361.html Sent from the Solr - User
> mailing list archive at Nabble.com.
