Hi Hoss,
I realize I'm reviving a really old thread, but I have the same need, and
SpanNumericRangeQuery sounds like a good solution for me. Can you give me
some guidance on how to implement that?
Thanks,
Wojtek
--
View this message in context:
http://lucene.472066.n3.nabble.com/One-item-multip
: parallel arrays, one array per address-part field. The parallel array
: alignment is effected via alignment of position increments. What's
: missing from Solr/Lucene is the ability to constrain matches such that
: the position increment of all matching address-part fields is the same.
It e
Hi David,
On 03/29/2010 at 4:54 PM, David Smiley (@MITRE.org) wrote:
> Did you read my original message where I suggested perhaps a solution
> might lie in intersecting different queries based on common multi-value
> field offsets derived from matching term positions? I have no idea how
> far off
-1863547009-13...@n3.nabble.com]
Sent: Monday, March 29, 2010 4:29 PM
To: Smiley, David W.
Subject: RE: One item, multiple fields, and range queries
Hi David,
On 03/29/2010 at 3:36 PM, David Smiley (@MITRE.org) wrote:
> I'm not sure what to make of "or index using a heterogeneous field
>
Hi David,
On 03/29/2010 at 3:36 PM, David Smiley (@MITRE.org) wrote:
> I'm not sure what to make of "or index using a heterogeneous field
> schema, grouping the different doc type instances with a unique key
> (the one) to form a composite doc"
Lucene is schema-free - you can mix and match differ
I'm not going to index each address as its own document because the
"one-side" that I have currently has loads of text and there are many
addresses. Furthermore, it doesn't really address the general case of my
problem statement.
I'm not sure what to make of "or index using a heterogeneous field
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)
On 29.03.2010, at 15:11, 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 o
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
address
TRE.org) [mailto:dsmi...@mitre.org]
> Sent: Sunday, March 28, 2010 6:01 PM
> To: solr-user@lucene.apache.org
> Subject: Re: One item, multiple fields, and range queries
>
>
> It's been three years since this discussion and I'm unaware of any work
> that
> has plug
It's been three years since this discussion and I'm unaware of any work that
has plugged this capability gap in Lucene/Solr. In summary, it would be
very, *very*, useful to be able to query multiple multi-valued fields and
require that such matches occur at the same index offset. I'm working on
: Now I follow. I was misreading the first comments, thinking that the field
: content would be deconstructed to smaller components or pieces. Too much
: (or not enough) coffee.
that's my bad .. i was trying to explain the concept by simplifying the
numeric range part out of the discussion and
Now I follow. I was misreading the first comments, thinking that the field
content would be deconstructed to smaller components or pieces. Too much
(or not enough) coffee.
I'm expecting the index doc needs to be constructed with lat/long/dates in
sequential order, i.e.:
123
32.123456
: OK, you lost me. It sounds as if this PhraseQuery-ish approach involves
: breaking datetime and lat/long values into pieces, and evaluation occurs
: with positioning. Is that accurate?
i'm not sure what you mean by pieces ... the idea is that you would have a
single "latitude" field and a sin
Yonik/Hoss -
OK, you lost me. It sounds as if this PhraseQuery-ish approach involves
breaking datetime and lat/long values into pieces, and evaluation occurs
with positioning. Is that accurate?
On 1/16/07, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 1/15/07, Chris Hostetter <[EMAIL PROTECTE
On 1/15/07, Chris Hostetter <[EMAIL PROTECTED]> wrote:
PhraseQuery artificially enforces that the Terms you add to it are
in the same field ... you could easily write a PhraseQuery-ish query that
takes Terms from differnet fields, and ensures that they appear "near"
eachother in terms of their to
: I've not yet used dynamic fields in this manner. With that number range,
: what limitations could I encounter? Given the size of that, I would need
very little, yonik recently listed the "costs" of dynamic fields...
http://www.nabble.com/Searching-multiple-indices-%28solr-newbie%29-tf2903899.
Thanks Hoss. Interesting approach, but the "N" bound could be well in the
hundreds, and the N bound would be variable (some maximum number, but
different across events.)
I've not yet used dynamic fields in this manner. With that number range,
what limitations could I encounter? Given the size
: 2) use multivalued fields as correlated vectors, so the first start
: date corresponds
:to the first end date corresponds to the first lat and long value.
: You get them all back
:in a query though, so your app would need to do extra work to sort
: out which matched.
if you expect a bou
Thanks Yonik.
1) model a single document as a single event at a singe place with a start
and end date.
This was my first approach, but at presentation time I need to display the
event once -- with multiple start/end dates and locations beneath it.
Is treating the given event uniqueId as a fac
On 1/12/07, Jeff Rodenburg <[EMAIL PROTECTED]> wrote:
I'm stuck with a query issue that at present seems unresolvable. Hoping the
community has some insight to this.
My index contains events that have multiple beginning/ending date ranges and
multiple locations. For example, event A (uniqueId
21 matches
Mail list logo
