Actually you have to mark the field as Field.Store.YES in order to see
that field when you retrieve the doc at search time.
You'll then be able to retrieve the string value.
Mike
On Thu, Apr 2, 2009 at 10:45 AM, David Seltzer wrote:
> Hi All,
> I have a document with a field called "TextTranscr
On Thu, Apr 2, 2009 at 2:26 PM, John Wang wrote:
> Hi Michael:
> Thanks for looking into this.
>
> Approach 2 has a dependency on how fast the delete set performs a check
> on a given id, approach one doesn't. After replacing my delete set with a
> simple bitset, approach 2 gets a 25-30% imp
>>> erickerick...@gmail.com 4/2/2009 10:24:42 AM >>>
>This seems really odd, especially with an index that size. The
>first question is usually "Do you open an IndexReader for
>each query?"
I'm using the Zend_Search_Lucene implementation so I'm really not sure
how it handles the IndexReader.
Hi Michael:
Thanks for looking into this.
Approach 2 has a dependency on how fast the delete set performs a check
on a given id, approach one doesn't. After replacing my delete set with a
simple bitset, approach 2 gets a 25-30% improvement.
I understand if the delete set is small, appr
Dear Shashi,
It should work now.
A temporary failure: our apologies.
thanks,
Glen
2009/4/2 Shashi Kant :
> Hi all, I have been trying to get the latest version of LuSQL from the
> NRC.ca website but get 404s on the download links. I have written to the
> webmaster, but anyone have the jar handy
Hi all, I have been trying to get the latest version of LuSQL from the
NRC.ca website but get 404s on the download links. I have written to the
webmaster, but anyone have the jar handy? Could I download from somewhere
else? or could you email it to me?
thanks,
Shashi
On Thursday 02 April 2009 15:36:44 David Seltzer wrote:
> Hi all,
>
>
>
> I'm trying to figure out how to use SpanNearQuery.getSpans(IndexReader)
> when working with a result set from a query.
>
>
>
> Maybe I have a fundamental misunderstanding of what an IndexReader is -
> I'm under the i
Try setting the minimum prefix length for fuzzy queries ( I think there is a
setting on QueryParser or you may need to subclass)
Prefix length of zero does edit distance comparisons for all unique terms e.g.
from "aardvark" to ""
Prefix length of one would cut this search space down to just
I think I have looked at constant score queries however, the relevance is of
value to the users so we left it as is. :(
Erick's idea of stripping terms with wildcards that has less then an acceptable
number of characters is a good idea and I might try it once I get the time.
Thanks,
M
___
Matt Schraeder wrote:
I've got a simple Lucene index and search built for testing purposes.
So far everything seems great. Most searches take 0.02 seconds or less.
Searches with 4-5 terms take 0.25 seconds or less. However, once I
began playing with fuzzy searches everything seemed to really sl
This seems really odd, especially with an index that size. The
first question is usually "Do you open an IndexReader for
each query?" If you do, be aware that opening a reader/searcher
is expensive, and the first few queries through the system are
slow as the caches are built up.
The second questi
I've got a simple Lucene index and search built for testing purposes.
So far everything seems great. Most searches take 0.02 seconds or less.
Searches with 4-5 terms take 0.25 seconds or less. However, once I
began playing with fuzzy searches everything seemed to really slow down.
A fuzzy search
You might try a constant score wildcard query (similar to a filter) - I
think you'd have to grab it from solr's codebase until 2.9 comes out
though. No clause limit, and reportedly *much* faster on large indexes.
--
- Mark
http://www.lucidimagination.com
Lebiram wrote:
Hi Erick
The query
On Wed, Apr 1, 2009 at 5:20 PM, Dan OConnor wrote:
> All:
>
> We are using java lucene 2.3.2 to index a fairly large number of documents
> (roughly 400,000 per day). We have divided the time history into various
> depths.
>
> Our first stage covers 8 days and our next stage covers 22. The index
I didn't code it, so I'm speaking at least second hand
It's a valid question whether having larger clauses is useful to
the user. Having a 1024 term OR clause isn't narrowing that much.
Plus, I think, it was a number that says, in effect, "you should know
that this is getting to be an expensiv
Hi All,
I have a document with a field called "TextTranscript". Its created
using the following command:
myDoc.add(new Field("TextTranscript", sTranscriptBody, Field.Store.NO,
Field.Index.TOKENIZED));
I'm then trying to retrieve the TokenStream by pulling the field.
Field fTextTranscript = lucDo
Hi Erick
The query was a test data basically in anticipation of searches on all indices
(4 index) with 12 million docs
that should yield very small results. Obviously that query does not happen in
real life but it did break the system.
If some user thought of just inputting random words then the
Hi all,
I'm trying to figure out how to use SpanNearQuery.getSpans(IndexReader)
when working with a result set from a query.
Maybe I have a fundamental misunderstanding of what an IndexReader is -
I'm under the impression that it's a mechanism for sequentially
accessing the documents in an
Ah, I get it now. Given that you bumped your max clause up, it makes
sense. I'm pretty sure that the wildcard expansion is the root or your
memory problems. The folks on the list helped me out a lot understanding
what wildcards were about, see the thread titled "I just don't get wildcards
at all" i
hi bonn,
can you give me the link you did read for substring matching
Thanks a lot
On 4/2/09, Bon wrote:
>
> Hi Matt,
>
> Thanks for your answer,
> I'm new to lucene, so I don't know what should I know about that.
> I find a reference about discuss searching substring and it work goo
Hi
>From the 2.4 javadocs for IndexWriter:
setDefaultWriteLockTimeout(long writeLockTimeout)
Sets the default (for any instance of IndexWriter) maximum time to
wait for a write lock (in milliseconds).
Lucene waits for the max specified time, retrying every 1000 millisecs
by default, then g
Hello
My code looks like this:
Directory dir = null;
try {
dir = FSDirectory.getDirectory("/path/to/dictionary");
SpellChecker spell = new SpellChecker(dir); // exception thrown here
// ...
dir.close();
} catch (IOException ex) {
log error
} finally {
if (dir!=null) {
tr
Hey,
Lucene is deployed at my Tomcat server, and when I send parallel calls from
my client to add, delete or update documents, some operations are
unsuccessful. The following exception is thrown:
org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out:
simplefsl...@d:\testIndex\wr
On Wed, Apr 1, 2009 at 6:37 PM, John Wang wrote:
> a code snippet is worth 1000 words :)
Here here!
OK, now I understand the difference.
With approach 1, for each of N UIDs you use a TermDocs to find the
postings for that UID, and retrieve the one docID corresponding to
that UID. You retrieve
Hi Erick,
I did a search just as JVM started... so I'm thinking that the JVM is busy with
some startup stuff... and that this search required more memory than what is
available at that time.
Had I done this search a while after the JVM has started, then this query
succeeds.
I then pump in se
25 matches
Mail list logo
