: 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
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
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
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
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 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
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
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
Mike Klaas wrote:
>
> Corresponds to:
> startOffset =
> tokenGroup.matchStartOffset;
> endOffset =
> tokenGroup.matchEndOffset;
> tokenText =
> text.substring(startOffset, endO
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
: 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
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@
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
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
14 matches
Mail list logo
