Hi Michel,
You can do all of this with Lucene however not with a standard index/query
operators. At Attivio we have a custom Lucene index structure + custom
query operators that support relational joins across records in an index. You
can write the queries in our standard query language or run
i'm looking at doing some statistical work with lucene searches and
the function queries look like a nice starting point. i found the
DocValues.getMin/Max/Avg functions already however there doesn't seem
to be a nice way to get to this information without doing a fair
amount of subclassing
n Aug 24, 2007, at 5:17 PM, Grant Ingersoll wrote:
Can you provide more details on what you are trying to do? Are you
trying to collect information from the FunctionQuery after it is done?
-Grant
On Aug 24, 2007, at 5:03 PM, Will Johnson wrote:
i'm looking at doing some statistical
;
System.out.println(q.getDocValues().getMinValue());
- will
On Aug 24, 2007, at 5:17 PM, Grant Ingersoll wrote:
Can you provide more details on what you are trying to do? Are you
trying to collect information from the FunctionQuery after it is done?
-Grant
On Aug 24, 2007, at 5:03 PM
a CustomScoreQuery combined with a FieldCacheSource that holds the
the lat/lon might work.
- will
On Aug 29, 2007, at 11:15 AM, Mike wrote:
I've searched the mailing list archives, the web, read the FAQ, etc
and I
don't see anything relevant so here it goes…
I'm trying to implement a rad
Don't forget the number 1 reason: speed. For certain types of queries a
search engine can return results orders of magnitude faster than a database.
I've seen search engines return hits in hundreds of milliseconds when the
same database query took hours or even days. That's not to say that a
sear
hat's because a database query returns a list of records,
whereas search engine returns only the links, not the actual content.
So a search engine works only in the index space, whereas a database
query engine would have to work in both index and content space...
ND
-Original Message
You could split up the field into 2 separate fields:
Postcode:NW10 7NY -> post1:NW10 post2:7NY
Then rewrite user's queries using the same logic: ie if the enter 1 term
'NW10' it gets rewritten to post1:NW10, if they enter 2 terms post1:NW10 AND
post2:7NY.
It also lets you do fuzzy search ie pos
Solr, which is built on top of lucene and adds highlighting among other
features, gets close to what you want. Check out:
http://wiki.apache.org/solr/HighlightingParameters
- will
-Original Message-
From: Erick Erickson [mailto:[EMAIL PROTECTED]
Sent: Friday, June 01, 2007 8:57 AM
To:
One other possibility I've used in the past:
Store 2 fields, one with the normal characters, one with each character
inversed, A->Z, Y->B, and so on. As long as you have the function to go
from the normal->reversed and reversed->normal you can iterate over both
fields in a forward only mode and j
10 matches
Mail list logo