Ah ha! Awesome thanks.
From: "Yonik Seeley" <[EMAIL PROTECTED]>
Reply-To: solr-user@lucene.apache.org
To: solr-user@lucene.apache.org
Subject: Re: Range search problem on float values
Date: Fri, 16 Feb 2007 01:01:33 -0500
On 2/16/07, Peter McPeterson <[EMAIL PROTECTED]> wrote:
Yonik, yes, I d
On 2/16/07, Peter McPeterson <[EMAIL PROTECTED]> wrote:
Yonik, yes, I did re-index the data after changing the field type. And
Chris, yes, I am using float.
Ah ha... the comments in the example schema say it all. You need
sfloat if you need range queries. Slightly confusing to have these
diff
Yonik, yes, I did re-index the data after changing the field type. And
Chris, yes, I am using float.
Any other thoughts on what could be causing it to behave this way? So weird
behaviour.
Thanks.
From: Chris Hostetter <[EMAIL PROTECTED]>
Reply-To: solr-user@lucene.apache.org
To: solr-user@
: Hi all, I'm having a problem doing a range search on float values. The field
: types for longitude and latitude were text, then I changed to float to give
: it a try but I'm still having problems.
are you using "float" or "sfloat" ... float stores floats, but doesn't so
the super special magic s
On 2/15/07, Peter McPeterson <[EMAIL PROTECTED]> wrote:
Hi all, I'm having a problem doing a range search on float values. The field
types for longitude and latitude were text, then I changed to float to give
it a try but I'm still having problems.
The correct search string would be:
latitude:[3
Mike Klaas wrote:
>
> Corresponds to:
> startOffset =
> tokenGroup.matchStartOffset;
> endOffset =
> tokenGroup.matchEndOffset;
> tokenText =
> text.substring(startOffset, endO
Hi all, I'm having a problem doing a range search on float values. The field
types for longitude and latitude were text, then I changed to float to give
it a try but I'm still having problems.
The correct search string would be:
latitude:[32.71852 TO 32.792765] AND longitude:[-117.159316 TO -11
I explicitly asked on java-user once, "Hey, how does/can this thing
workblah blah", but got no responses. As far as I know, Chuck is the only
ParallelReader users. :)
Otis
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Simpy -- http://www.simpy.com/ - Tag - Search - Shar
On 2/15/07, nick19701 <[EMAIL PROTECTED]> wrote:
Best buy - Acer Aspire AS5610-2273 - $599. Windows vista, 1 GB RAM
Doesn't look particularly out of the ordinary.
The exception is like this:
java.lang.StringIndexOutOfBoundsException: String index out of range: -52
at java.lang.S
Thanks for the report Nick,
could you open a JIRA bug for this?
Thanks,
-Yonik
On 2/15/07, nick19701 <[EMAIL PROTECTED]> wrote:
I have thousands of docs in my solr instance.
The following doc (maybe others) is causing exception everytime
highlight is turned on.
Best buy - Acer Aspire AS5610-
On Feb 15, 2007, at 2:55 AM, Otis Gospodnetic wrote:
Then you'd keep your big fields in one index, and the frequently
modified and shorter fields in another index. But I never
understood how you'd keep doc IDs in sync between the two, which is
something that ParallelReader requires.
I've
On 2/15/07, Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
One way around this is to get support for ParallelReader (I believe
ParallelWriter is still in JIRA, contributed by Chuck) into Solr.
http://lucene.apache.org/java/docs/api/org/apache/lucene/index/ParallelReader.html
Then you'd keep your b
I have thousands of docs in my solr instance.
The following doc (maybe others) is causing exception everytime
highlight is turned on.
Best buy - Acer Aspire AS5610-2273 - $599. Windows vista, 1 GB RAM
The exception is like this:
java.lang.StringIndexOutOfBoundsException: String index out
: id
: document_title
:
whoa... that's a pretty out there usecase ... i don't think i've ever seen
someone use their uniqueKey field as the target of a copyField.
off the top of my head, i suspect maybe the copy field is taking place
after the duplicate detection? ... but i'm not sure...
: W
14 matches
Mail list logo
