On Sep 22, 2006, at 8:51 PM, Chris Hostetter wrote:
: Anyway, the id-generation implementation is hidden (package
: protected), so I guess it should be fine to put it in Lucene.
: Any objections?
nope .. +1 for promoting to lucene/java
+1
and
Is now the time to consider promoting Func
: Indeed the first version I wrote followed the pattern you suggest (let's
: name it pattern_1 for the discussion). However with pattern_1 I could not
: cover the case of a method originally not throwing an exception. The
: problem is that in pattern_1 we have to catch the exception before decidin
: Well I am not authorized to give you the entire trace, but here is the
: iimportant part...
:
: org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:79)
: org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:71)
: org.apache.lucene.search.PrefixQuery.rewrite(PrefixQuery.java:50)
: o
: Anyway, the id-generation implementation is hidden (package
: protected), so I guess it should be fine to put it in Lucene.
: Any objections?
nope .. +1 for promoting to lucene/java
Is now the time to consider promoting FunctionQuery too :)
-Hoss
djd0383 <[EMAIL PROTECTED]> wrote on 22/09/2006 17:01:47:
>
> And why would Lucene be doing that now? That just doesn't seem to be the
> right thing to do.
>
This would depend on the analyzer being used.
It puzzles me that you say the user query is "1" but the query that throws
the exception is P
On 9/22/06, djd0383 <[EMAIL PROTECTED]> wrote:
And why would Lucene be doing that now? That just doesn't seem to be the
right thing to do.
It's often not the right thing to do, but it's all under your control.
It depends on exactly what your analyzer looks like (what tokenizers
and tokenfilter
And why would Lucene be doing that now? That just doesn't seem to be the
right thing to do.
Yonik Seeley wrote:
>
> On 9/22/06, djd0383 <[EMAIL PROTECTED]> wrote:
>> Also, I forgot to mention, but the error is throwing a message implying
>> it
>> cannot search on null.
>
> The analyzer you a
On 9/22/06, djd0383 <[EMAIL PROTECTED]> wrote:
Also, I forgot to mention, but the error is throwing a message implying it
cannot search on null.
The analyzer you are using is throwing away the "1" leaving nothing
left to search on.
-Yonik
http://incubator.apache.org/solr Solr, the open-source
Well I am not authorized to give you the entire trace, but here is the
iimportant part...
org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:79)
org.apache.lucene.search.BooleanQuery.add(BooleanQuery.java:71)
org.apache.lucene.search.PrefixQuery.rewrite(PrefixQuery.java:50)
org.apache
What is the exception stack trace?
djd0383 <[EMAIL PROTECTED]> wrote on 22/09/2006 16:07:53:
>
> I am managing a few Lucene searches in the application that I am
building.
> We have noticed that when a user searches with the string "1", this will
> throw an exception. The search works fine until
I am managing a few Lucene searches in the application that I am building.
We have noticed that when a user searches with the string "1", this will
throw an exception. The search works fine until Lucene tries to build its
Hits. Is there any reason why this would be true? Also, what is a common
On 9/22/06, Andi Vajda <[EMAIL PROTECTED]> wrote:
A PyLucene user just submitted a patch to PyLucene to integrate Solr's
PrefixFilter class. PyLucene is not PySolr but it looks like PrefixFilter has
nothing specific to Solr in it and PrefixFilter could be useful to regular
Lucene users as well.
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436980 ]
Doron Cohen commented on LUCENE-675:
Few things that would be nice to have in this performance package/framework -
() indexing only overall time.
() indexing
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436979 ]
Michael McCandless commented on LUCENE-675:
---
I agree: a simple ant-accessible benchmark to enable "before and
after" runs is an awesome step forward. And
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436972 ]
Dawid Weiss commented on LUCENE-675:
First -- I think it's a good initiative. Grant, when you're thinking about the
infrastructure, it would be pretty neat to
A PyLucene user just submitted a patch to PyLucene to integrate Solr's
PrefixFilter class. PyLucene is not PySolr but it looks like PrefixFilter has
nothing specific to Solr in it and PrefixFilter could be useful to regular
Lucene users as well.
Are there any objections to checking org.apach
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436949 ]
Grant Ingersoll commented on LUCENE-675:
My comments are marked by GSI
---
In the mean time I've been using Europarl for my testing.
GSI: perhaps
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436934 ]
Mike Klaas commented on LUCENE-675:
---
A few notes on benchmarks:
First, it is important to realize that no benchmark will ever fully-capture all
aspects of lucen
Afternoon (here anyway),
I think understanding Solr's overall approach (whose design I believe
came out of the thread you've referenced) is also a good step here.
Even if you can't re-use the hard links trick, you might be able to
reuse its snapshotting & index distribution protocol.
I'll ha
[
http://issues.apache.org/jira/browse/LUCENE-675?page=comments#action_12436858 ]
Michael McCandless commented on LUCENE-675:
---
I think this is an incredibly important initiative: with every
non-trivial change to Lucene (eg lock-less com
I think this is a great question ("what's the best way to really scale
up Lucene?"). I don't have alot of experience in that area so I'll
defer to others (and I'm eager to learn myself!).
I think understanding Solr's overall approach (whose design I believe
came out of the thread you've referen
[ http://issues.apache.org/jira/browse/LUCENE-675?page=all ]
Grant Ingersoll reassigned LUCENE-675:
--
Assignee: Grant Ingersoll
> Lucene benchmark: objective performance test for Lucene
> ---
>
>
Doron Cohen wrote:
For obtain(timeout), to prevent waiting too long you could compute the
maximum number of times that obtain() can be executed (assuming, as in
current code, that obtain() executes in no time). Then break if either it
was executed sufficiently many times or if time is up. I don't
Yonik Seeley wrote:
On 9/21/06, Michael McCandless <[EMAIL PROTECTED]> wrote:
Anyway, my first reaction was to change this to use
System.currentTimeMillis() to measure elapsed time, but then I
remembered is a dangerous approach because whenever the clock on the
machine is updated (eg by a time-s
24 matches
Mail list logo
