Chris Hostetter wrote:
: I think that overriding getFieldQuery would work, yeah... you're right.
:It's just a matter of comparing efficienty of this:
:
: BooleanQuery of (TermQuery, FilteredQuery of (AllDocsQuery, Filter))
:
: to the efficiency of this:
:
: FilteredQuery of (TermQue
From: Chris Hostetter <[EMAIL PROTECTED]>
To: java-user@lucene.apache.org
Sent: Thu 09 Feb 2006 02:06:55 AM EST
Subject: Re: Queries not derived from the text index
: I think that overriding getFieldQuery would work, yeah... you're right.
:It's just a matter of compari
: I think that overriding getFieldQuery would work, yeah... you're right.
:It's just a matter of comparing efficienty of this:
:
: BooleanQuery of (TermQuery, FilteredQuery of (AllDocsQuery, Filter))
:
: to the efficiency of this:
:
: FilteredQuery of (TermQuery, Filter)
the third o
Erik Hatcher wrote:
Actually I'm pretty certain that it'll work with just getFieldQuery
overriding. You can AND or OR a FilteredQuery with any other Query
inside a BooleanQuery. I'd be surprised if it didn't work. Scoring is
the one tricky caveat to this sort of thing, and perhaps the new
"
On Feb 8, 2006, at 6:46 PM, Daniel Noll wrote:
Erik Hatcher wrote:
One interesting option is to subclass QueryParser and override
getFieldQuery. When the field is "tag", return a FilteredQuery
(see trunk codebase, or the nightly 1.9 binaries) using a Filter
that interfaces with your data
Erik Hatcher wrote:
One interesting option is to subclass QueryParser and override
getFieldQuery. When the field is "tag", return a FilteredQuery (see
trunk codebase, or the nightly 1.9 binaries) using a Filter that
interfaces with your database. Caching of the filters would be
desirable for
John Powers wrote:
This may be a tangent, but for my filters and searches, I construct the
query with "+" and "-" and what not.. is this not the right way to do
this?I haven't had to extend or write any special AND or OR classes,
I just write the query and search the once. Any advantage
vantage to writing
Filter subclasses?
-Original Message-
From: Daniel Noll [mailto:[EMAIL PROTECTED]
Sent: Tuesday, February 07, 2006 5:18 PM
To: java-user@lucene.apache.org
Subject: Re: Queries not derived from the text index
Erik Hatcher wrote:
>
> On Feb 7, 2006, at 1:09 AM, Da
On Feb 7, 2006, at 6:17 PM, Daniel Noll wrote:
So a user might want to enter something like this:
text:camel AND tag:zoo
In this case we would want a real FieldQuery object for the
text:camel portion, and a non-Lucene Query instance for the
"tag:zoo" portion which actually queries the
Erik Hatcher wrote:
On Feb 7, 2006, at 1:09 AM, Daniel Noll wrote:
I've got an unusual (if not crazy) question about implementing custom
queries.
Basically we have a UI where a user can enter a query and then select
a bunch of filters to be applied to the query. These filters are
currently
On Feb 7, 2006, at 1:09 AM, Daniel Noll wrote:
I've got an unusual (if not crazy) question about implementing
custom queries.
Basically we have a UI where a user can enter a query and then
select a bunch of filters to be applied to the query. These
filters are currently implemented using
Daniel Noll wrote:
Is it possible to customise the QueryParser so that it returns Query
instances that have no relationship to the text index whatsoever?
The syntax that Lucene's QueryParser supports isn't very complicated.
I'm sure you could write your own parser from scratch, perhaps with s
Hi.
I've got an unusual (if not crazy) question about implementing custom
queries.
Basically we have a UI where a user can enter a query and then select a
bunch of filters to be applied to the query. These filters are
currently implemented using a fairly simple wrapper around Lucene's own
13 matches
Mail list logo