Hi,
You'd need to either expand the query or index the documents in a manner
that they store the extra ontology related information. You may try going
for the later option in case your mappings change often, though it'd be slow
as you'd be adding more terms to the query.
You could try using someth
Hi Ravi,
Adding to what Erick said, you could do index the numbers as numeric fields
instead of strings. This should improve things for you by a considerable
amount.
P.S: I'm talking with my knowledge on Java Lucene.
--
Anshum Gupta
Naukri Labs!
http://ai-cafe.blogspot.com
The facts expressed her
Dear all,
I want to provide hierarchical matching in Lucene. For example,
in a document, there is a field and its value:
transportation: vehicle
and suppose there is a class/subclass relationship saying that
car is a subclass of vehicle, and bus is a subclass of vehicle.
I want the query:
tran
You have to provide more info, especially the search code you're
using. How many documents in your index? What are you measuring?
Anything else you can think of that might help people diagnose
your issue.
Also, consider asking on the .Net user's list.
Known things to look for (in Java).
1> Are y
Using Lucene.Net
I've built an index of documents.
The documents also have a unique identifier (my identifier, not the lucene
index's id).
The unique identifers are also a sort order of new-ness (higher id values are
newer)
string my_id ="1234"
doc.Add(new Field("id", my_id, Fie
Hello folks,
Those of you in or near NYC and using Lucene or Solr should come to "Lucandra -
a Cassandra-based backend for Lucene and Solr" on April 26th:
http://www.meetup.com/NYC-Search-and-Discovery/calendar/12979971/
The presenter will be Lucandra's author, Jake Luciani.
Please spread the
Hi Koji,
Thank you again for your continued assistance.
The code below details the code I used in Lucene 2.4 to highlight terms
(which did not correctly highlight terms).
>From your previous email, is there a way to access a TermVector
containing only matched terms, or is my previous approach stil
Thanks Mike.
That solved a query which was itching my mind for a long time.
On Thu, Apr 22, 2010 at 4:41 PM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> It's the IndexReader that's costly to open/warm, so ideally it should
> be opened once and shared.
>
> The Searchers do very little
It's the IndexReader that's costly to open/warm, so ideally it should
be opened once and shared.
The Searchers do very little on construction so re-creating per query
should be OK.
Mike
On Thu, Apr 22, 2010 at 6:38 AM, Samarendra Pratap wrote:
> Greetings to all.
> I have read at so many place
Greetings to all.
I have read at so many places that we should not open a Searcher for each
request for the sake of performance, but I have always been wondering
whether it is actually Searcher or Reader?
I have a group of index amounting to 23G which actually contains of
different index directo
10 matches
Mail list logo