Hi all,
I have a document with a date in it and I put it into a field like so:
DateTools.dateToString(theDate, Resolution.DAY),
Field.Index.UN_TOKENIZED.
What I find is that a range query works:
[20060131 TO 20060601] and wildcard works e.g.
2006*
but exact matches do not work e.g.
20060130
Any
-- Forwarded message --
From: pepone pepone <[EMAIL PROTECTED]>
Date: Apr 9, 2006 1:42 AM
Subject: Re: HOT SPOT VIRTUAL MACHINE aleatory crash while index documents
To: Daniel Naber <[EMAIL PROTECTED]>
i change to Sun JVM but crash persist the crass is a lot aleatory and
occurrs a
I noticed when using the Luke tool that I it provides a set of top words
from an index. What is a programmatic way of doing this?
--
Berlin Brown
(ramaza3 on freenode)
http://www.newspiritcompany.com
also checkout alpha version of botverse:
http://www.newspiritcompany.com:8086/universe_home
Chris:
Thanks for that exposition, that helps me greatly. I didn't mention that I
tried increasing the MaxAllowedClause count and ran out of memory. And that
I don't trust those kinds of tweaks anyway. They'll blow up sometime,
somewhere and I'll get a phone call because our product is offline an
OK, I get it now. Obviously I didn't read your response as you meant it and
was focusing on the optimization part.
I'd also agree that using the most specific tool for the task is better
design. There's also an argument that "I'd rather have a library fail than
do something non-obvious". I'll leav
: If I understand this right, I could build my own BooleanQuery in chunks of,
: say, 1,000 terms each by just adding words given me by the WildCardTermEnum,
: right?
if you took that approach, you would avoid getting a TooManyClauses
exception, but you could far more easily avoid it by increasein
I don't mean literally that WildcardQuery would morph into a
TermQuery, but rather "behave" like it by simply doing what it
currently does but without the string index exception that currently
is thrown. It wouldn't take any additional clockticks, per se, I
don't think - it'd just behave a
8 apr 2006 kl. 19.04 skrev Erick Erickson:
I have to disagree.
Optimization where it really doesn't count is, in my experience, bad.
Period.
My intent was not to ephasise on optimization. The waste of
clockticks is just a side effect from what I consider bad design.
WildcardQuery and T
I have to disagree. Nowhere in the javadoc is this condition noted. There is
no way for a user to know that this is a restriction, and forcing developers
to find this by having a program fail, even with a better error message,
is...er...unfortunate. Even if this were in the javadoc, I still have to
As far as I know, Compass Framework does not store index into
database. It just index data when data pass Hibernate, iBatis, or
other layer.
So if you use these layers in your code, you can use Compass.
Chris Lu
--
Full-Text Lucene Search on Any Databases
http:
8 apr 2006 kl. 13.06 skrev Erik Hatcher:
Feel free to log this as a bug report in our JIRA issue tracker.
It seems like a reasonable change to make, such that a
WildcardQuery without a wildcard character would behave like
TermQuery.
-1
Even though very few, it is a waste of clockticks.
Erik:
Thanks, that helps a lot. I won't waste any more time chasing CSRQ, which is
definitely a plus.
I have to admit that I was hoping for a "RTFM, page ### (Read The FIELD
Manual))" response. Although since I completely missed WildCardTermEnum
maybe I *did* get the response I hoped for. I have
Feel free to log this as a bug report in our JIRA issue tracker. It
seems like a reasonable change to make, such that a WildcardQuery
without a wildcard character would behave like TermQuery.
Erik
On Apr 7, 2006, at 10:28 AM, Erick Erickson wrote:
So I'm trying to do silly stuff,
Eric,
Wildcard queries are tricky business. WildcardQuery by itself
without leveraging any analysis tricks is what you've got, but you
may want to consider injecting rotated tokens. For example, the word
cat would be indexed as "cat$", "at$c", "t$ca", and "$cat" (all in
the same positio
Database implementation of the index is always bound to be slow compared to
storing it on the filesystem.
Probably the group which stores indexes into Berkley DB should be able to
give you a performance measuer of what will happen you store indexex in
databases.
Rgds
Prabhu
On 4/8/06, Marios Sk
Hi all,
I recently came across the Compass Framework, which is built on top of lucene. I
am interested in it because it stores the lucene index in an RDBMS and provides
transaction support for index updates (it also has several other features but
this is the part I'm mostly interested in).
I w
16 matches
Mail list logo
