On Wednesday 26 April 2006 00:40, Boris Galitsky wrote:
Hello
We need to construct nested span queries, and it seems like SrndQuery
is a good way to do it.
Are there examples available for SrndQueries? How to construct them
(is it using QueryParser?).
Where to get Surround Parser?
On Apr 26, 2006, at 2:52 AM, Paul Elschot wrote:
Iirc in the contrib area there is also an xml query parser that allows
xml structured queries, but at the moment I don't know precisely
where that is.
http://svn.apache.org/repos/asf/lucene/java/trunk/contrib/xml-query-
parser/
I have a simple request that applies to org.apache.lucene.util.Parameter, but
before I go suggesting things to add to Lucene, a quick introduction: I'm Joe,
I'm working for a company that's using Lucene to build large-ish indexes of
documents for clients who'd like to securely store their
Oops - I just realized you're maintaining a static map of these parameters in
the Parmeter class. Should have looked more closely before writing - sorry
'bout that.
Glad I at least got the intro correct.
-j
--- Joe R [EMAIL PROTECTED] wrote:
I have a simple request that applies to
MatchAllDocsQuery, MultiSearcher and a custom HitCollector throwing exception
-
Key: LUCENE-556
URL: http://issues.apache.org/jira/browse/LUCENE-556
Project: Lucene - Java
Type: Bug
Hello,
In:
public abstract class IndexOutput
public void writeVInt(int i)
writeByte((byte)((i 0x7f) | 0x80));
I thought
(byte)((i 0x7f) | 0x80) == (byte)(i | 0x80)
As (byte) is able to truncate the last byte for us already, no need of
( 0x7f). If so, we may change that line to
On 4/26/06, Charlie [EMAIL PROTECTED] wrote:
I thought
(byte)((i 0x7f) | 0x80) == (byte)(i | 0x80)
As (byte) is able to truncate the last byte for us already, no need of
( 0x7f). If so, we may change that line to
writeByte((byte)(i | 0x80));
and may speed up a little bit. Correct
karl wettin wrote:
karl wettin wrote:
This could lead me to believe I can use different boost for fields
with the same name within one document.
You can. The values are multiplied to produce the final boost value
for the field.
It's not really the same thing as I tried to describe
ok, thanks for your reply.
But I thought
Method: public void writeVInt(int i)
is not about UTF-8, it is about how to write an int in variable length.
Is it included as a part of future unicode character writing?
--
Best regards,
Charlie
---
I thought
(byte)((i 0x7f) | 0x80) ==
On 4/26/06, Charlie [EMAIL PROTECTED] wrote:
ok, thanks for your reply.
But I thought
Method: public void writeVInt(int i)
is not about UTF-8, it is about how to write an int in variable length.
Oh, sorry... wrong function. It was a similar optimization to things
I had seen in the char
On Apr 26, 2006, at 10:21 AM, Charlie wrote:
But I thought
Method: public void writeVInt(int i)
is not about UTF-8, it is about how to write an int in variable
length.
Is it included as a part of future unicode character writing?
WriteVInt, and also WriteVLong, which contains the same
On 4/26/06, Charlie [EMAIL PROTECTED] wrote:
writeByte((byte)((i 0x7f) | 0x80));
writeByte((byte)(i | 0x80));
Yes, these two lines are equivalent.
It's fairly likely that the JVM already does this optimization for you though...
at least gcc -O already compiles to identical assembly for
On 4/26/06, Marvin Humphrey [EMAIL PROTECTED] wrote:
So the question is, does this assertion hold?
(byte)((i 0x7f) | 0x80) == (byte)(i | 0x80)
Yes.
I tested just this out, and java5 -server reports a 15% performance boost for
writeVInt alone, tested over numbers from 1 to 100. Of
[
http://issues.apache.org/jira/browse/LUCENE-497?page=comments#action_12376538 ]
Hoss Man commented on LUCENE-497:
-
This bug should be resolved as INVALID
update copyright (and licence) prior to release of 1.9
[ http://issues.apache.org/jira/browse/LUCENE-497?page=all ]
Yonik Seeley closed LUCENE-497:
---
Resolution: Invalid
Closing.
update copyright (and licence) prior to release of 1.9
--
This originated on the Solr mailing list.
That's the way Lucene changes.
I was thinking you implied that you knew of someone who had customized their
own, but it was a closed source solution. And if so then you would know how
that project faired.
I definitely sounds like an interesting
jason rutherglen wrote:
I was thinking you implied that you knew of someone who had customized their own, but it was a closed source solution. And if so then you would know how that project faired.
I don't recall the details, but I know folks have discussed this
previously, and probably
On 4/26/06, jason rutherglen [EMAIL PROTECTED] wrote:
As this would be used with Solr I wonder if there would be a good way to also
update the Solr caches.
Other than re-executing queries that generated the results? Probably not.
The nice thing about knowing exactly when the view of an index
--- Yonik Seeley [EMAIL PROTECTED] wrote:
On 4/26/06, Charlie [EMAIL PROTECTED] wrote:
writeByte((byte)((i 0x7f) | 0x80));
writeByte((byte)(i | 0x80));
Yes, these two lines are equivalent.
It's fairly likely that the JVM already does this
optimization for you though...
at least
search vs explain - score discrepancies
---
Key: LUCENE-557
URL: http://issues.apache.org/jira/browse/LUCENE-557
Project: Lucene - Java
Type: Bug
Components: Search
Reporter: Hoss Man
I'm on a mission to demonstrate
[ http://issues.apache.org/jira/browse/LUCENE-557?page=all ]
Hoss Man updated LUCENE-557:
Attachment: LUCENE-557-modify-existing-tests.patch
Phase one: stealthily modify (almost) all tests that use an IndexSearcher to
use a new subclass which will check
If I'm following this correctly, it omits a related issue which is the
need to periodically close and reopen the IndexWriter in order to flush
its internal RAMDirectory, and similarly for the IndexReader used for
delete. Is there any good solution to avoid these as well?
My app has an
I've submited a ThaiAnalyzer for Lucene here
http://issues.apache.org/jira/browse/LUCENE-503?page=all
I want to contribute the code and have signed the CLA.
Can anyone review the code?
--
_/|\_ Samphan Raruenrom. Open Source Development Co., Ltd.
Tel: +66 38 311816, Fax: +66 38 773128,
23 matches
Mail list logo
