If you are only using filters and no Query (esp. pass an empty BooleanQuery
to search()) it would return no documents. An empty BooleanQuery never
returns result, so there is nothing to filter.
You have two possibilities: if there are no query clauses, add a
MatchAllDocsQuery() to hit all and filt
The last few versions of lucene have deprecated several of the
interfaces we were using and this is necessitating a fairly major
upgrade of our code (which hasn't had much done to it for several
years). I'm not complaining; the changes are probably necessary.
In reading LIA2, I've learned abou
Exactly. Thanks.
-Original Message-
From: João Silva [mailto:galaio.si...@gmail.com]
Sent: Tuesday, June 16, 2009 4:47 PM
To: java-user@lucene.apache.org
Subject: Re: Determining lucene version programmatically
hi ssmith,
is this what you need?
LucenePackage.get().getImplementationVe
Mostly, our users want to see search results in reverse date order
(newer hits first). I know how to do that with a Sort object and it
works fine.
However, sometimes our users want to do a search and get results in date
order starting at a certain date. Say for example, they want to start
the
hi ssmith,
is this what you need?
LucenePackage.get().getImplementationVersion();
cheers,
João
On Tue, Jun 16, 2009 at 11:36 PM, Scott Smith wrote:
> Is there any way to programmatically determine the version of lucene
> being loaded?
>
>
>
>
--
Cumprimentos,
João Carlos Galaio da Silva
Is there any way to programmatically determine the version of lucene
being loaded?
NOT isn't a boolean operator, which is a source of continuous confusion.
See:
http://lucene.apache.org/java/2_3_2/queryparsersyntax.html#NOT
for a part of the explanation, and
http://wiki.apache.org/lucene-java/BooleanQuerySyntax
Best
Erick
On Tue, Jun 16, 2009 at 11:24 AM, Sumanta Bhowmik <
sum
Michael, here is the Solr change:
http://issues.apache.org/jira/browse/SOLR-1078
Here is the issue to import it into lucene.
http://issues.apache.org/jira/browse/LUCENE-1377
On Tue, Jun 16, 2009 at 6:01 AM, Michael
McCandless wrote:
> On Mon, Jun 15, 2009 at 1:14 PM, Robert Muir wrote:
>
>> I'm
LUCENE-1313 is just an enhancement to near real-time search that won't
make it into 2.9 at this point (we are "gunning" to get 2.9 out the
door...).
Ie, near real-time search was already committed to trunk, under LUCENE-1516.
Mike
On Tue, Jun 16, 2009 at 7:08 AM, João Silva wrote:
> Thanks mike,
Yes, thanks! I'll start with a simple one as you described and test on the
languages we have at the moment.
-Original Message-
From: Robert Muir [mailto:rcm...@gmail.com]
Sent: Monday, June 15, 2009 10:45 PM
To: java-user@lucene.apache.org
Subject: Re: Lucene and multi-lingual Unicode -
Thanks mike, i will see that.
The ticket for that functionallity is the Lucene-1313?
Thanks,
João
On Tue, Jun 16, 2009 at 11:53 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> Have you tried the patch on LUCENE-1026? It's rather standalone from
> Lucene's core -- it adds a conven
Have you tried the patch on LUCENE-1026? It's rather standalone from
Lucene's core -- it adds a convenience layer (for interleaving
reads/writes) on a single index.
Or, code it up yourself. As of 2.9 (not yet released -- available on
trunk now), near real-time search makes this particularly simp
Hi
I found that a query "NOT num_pkts:1024 OR src_port:80" behaves the same as
"NOT num_pkts:1024 AND src_port:80". The actual query is
(start_utc:[1230748200 TO 1230768000] OR end_utc:[1230748200 TO 1230768000])
AND (num_pkts:1024 OR NOT num_bytes:40960) but it behaves as if it is
(
I mike, thanks.
I rewrite my problem:
I trying to implement a web tool for uploading documents,
for now i'm implementing basic operations, to upload the
and retrieve the users files, so it can read and/or
modify/delete them.
Imagine tha i have several users performing that operations,
is there a
On Tue, Jun 16, 2009 at 6:03 AM, Simon
Willnauer wrote:
> Mike I guess you mean a single VM (JRE rather refers to a version or
> vendor) - Just wanna clarify.
Right, I meant a "single java process", so I guess an instance of a JVM?
Within that instance, many threads can be doing writing against
On Tue, Jun 16, 2009 at 11:59 AM, Michael
McCandless wrote:
> Concurrency using multiple threads in a single JRE is perfectly fine
> and strongly encouraged, since modern hardware is very concurrent.
>
> But, concurrent access via different JREs is not supported by Lucene.
> Lucene's write lock wil
Thanks Manish for your fast answer.
I trying to implement a web tool for uploading documents,
for now i'm implementing basic operations, to upload the
and retrieve the users files, so it can read and/or
modify/delete them.
Imagine tha i have several users performing that operations,
is there any i
On Mon, Jun 15, 2009 at 1:14 PM, Robert Muir wrote:
> I'm not personally biased one way or the other for any particular
> framework, but recently there has been some improvements added to SolR
> so that the default type 'text' is pretty good for multilingual
> processing.
Robert can you describe
Concurrency using multiple threads in a single JRE is perfectly fine
and strongly encouraged, since modern hardware is very concurrent.
But, concurrent access via different JREs is not supported by Lucene.
Lucene's write lock will protect the index against such cases, but if
you bypass the write l
Concurrently adding updating deleting may not be good idea.It may corrupt
the index
-Manish B. Joshi
On Tue, Jun 16, 2009 at 2:33 PM, João Silva wrote:
> Hi,
> how can i access the index in a concurrently way,
> so i can perform add/update/delete documents concurrently?
>
> Cheers,
> João
>
> --
Hi,
how can i access the index in a concurrently way,
so i can perform add/update/delete documents concurrently?
Cheers,
João
--
Cumprimentos,
João Carlos Galaio da Silva
21 matches
Mail list logo
