-item-multiple-fields-and-range-queries-tp475030p2796613.html
Sent from the Solr - User mailing list archive at Nabble.com.
: 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
lways
satisfactory.
~ 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-tp475030p684282.html
Sent from the Solr - User mailing list archive at Nabble.com.
>
> ~ 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.
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
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.
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
ld take some serious hacking and I have no clue how feasible
that is. Thoughts?
~ David Smiley
--
View this message in context:
http://n3.nabble.com/One-item-multiple-fields-and-range-queries-tp475030p682227.html
Sent from the Solr - User mailing list archive at Nabble.com.
: 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
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 = 123) occurs every
weekend, sometimes in one location,
22 matches
Mail list logo
