[
http://issues.apache.org/jira/browse/LUCENE-662?page=comments#action_12437543 ]
Grant Ingersoll commented on LUCENE-662:
Haven't looked fully at the patch, but one thing I am curious about is why
remove the Fieldable interface?
Hello,
I have just started to work with Lucene
Is it possible to define the index files of lucene to be on a database
(such as MySql), just for backup and restore porposes
Thanks in Advance
Reuven Ivgi
Have a look at the compass framework
http://www.opensymphony.com/compass/
Compass also provides a Lucene Jdbc Directory implementation, allowing
storing Lucene index within a database for both pure Lucene
applications and Compass enabled applications.
best regards simon
On 9/25/06, Reuven Ivgi
The top of the stack was the stack I posted. I am not able to give the
entire stack, but this is the important part. The exception is something
about searching with null.
When I say that I am searching for '1', the user is phyisically entering '1'
into the search form and submitting. This
On Sep 24, 2006, at 11:44 PM, David Balmain wrote:
Hi Greg,
I don't know which documentation of the Lucene FileFormat you are
looking at but you can see UInt32 (Int) UInt64 (Long) and VInt defined
here:
http://lucene.apache.org/java/docs/fileformats.html
That's where I was looking.
Given the trouble people routinely get themselves into using RangeQuery would
it make sense to change the rewrite method to generate a ConstantScoreQuery
wrapping a RangeFilter?
The only disadvantages I can see would be:
1) Scoring would change - some users may find their apps produce
My QueryParser looks like this:
query = QueryParser.parse(1*,allText,analyzer);
analyzer is predetermited for this class. Is there something special I
should be setting in this to allow for this search string?
Thanks again!
Doron Cohen wrote:
djd0383 [EMAIL PROTECTED] wrote on
For real search engine, performance is the most important factor. I think
file system based system is better than storing the indexes in database
because of the pure speed you will get.
Cheers,
Jian
On 9/25/06, Simon Willnauer [EMAIL PROTECTED] wrote:
Have a look at the compass framework
My QueryParser looks like this:
query = QueryParser.parse(1*,allText,analyzer);
analyzer is predetermited for this class. Is there something special I
should be setting in this to allow for this search string?
Is it a custom analyzer or one of Lucene's analyzers?
Examining the result query
Those two message print the following:
For qtxt 1* the result query is allText:1*
and
The analyzer in use is: org.apache.lucene.analysis.standard.StandardAnalyzer
- org.apache.lucene.analysis.standard.StandardAnalyzer
I hope this helps. Thank you for all your help.
Doron Cohen wrote:
djd0383 [EMAIL PROTECTED] wrote on 25/09/2006 11:21:13:
Those two message print the following:
For qtxt 1* the result query is allText:1* and
The analyzer in use is:
org.apache.lucene.analysis.standard.StandardAnalyzer
This output seems ok - the analyzer is standard and seems to me the result
[
http://issues.apache.org/jira/browse/LUCENE-662?page=comments#action_12437644 ]
Nicolas Lalevée commented on LUCENE-662:
It is due to lazy loading. A lazy field, when being retreived data, have to
know how to read the stream. In the
[ http://issues.apache.org/jira/browse/LUCENE-676?page=all ]
Andi Vajda updated LUCENE-676:
--
Attachment: PrefixFilter.java
Attached is a version of PrefixFilter that could be added to the Lucene core as
submitted by Yura Smolsky, a PyLucene user.
What are the Store and Index classes? It does not seem that my version of
Lucene is using them
Doron Cohen wrote:
djd0383 [EMAIL PROTECTED] wrote on 25/09/2006 11:21:13:
Those two message print the following:
For qtxt 1* the result query is allText:1* and
The analyzer in use is:
djd0383 [EMAIL PROTECTED] wrote on 25/09/2006 14:17:56:
What are the Store and Index classes? It does not seem that my version
of
Lucene is using them
That code was using Lucene 2.0.
In Lucene 1.4.3 you would add the docs like this:
boolean store = false;
boolean index = true;
: The top of the stack was the stack I posted. I am not able to give the
: entire stack, but this is the important part. The exception is something
: about searching with null.
when i say the top of the stack trace i mean what you just described:
something about searching with null .. what
This question was raised in the user's list -
http://www.nabble.com/highlighting-tf2322109.html
Assume three fragments and two queries:
f1 = aa 11 bb 33 cc
f2 = aa 11 bb 11 cc
f3 = aa 11 bb 22 cc
q1 = 11 22
q2 = 11
Now we call highlighter.getBestFragment(q);
For q1, f3 is
: Given the trouble people routinely get themselves into using RangeQuery
: would it make sense to change the rewrite method to generate a
: ConstantScoreQuery wrapping a RangeFilter?
As much as i hate RangeQuery, i can imagine situations where people wnat
the scoring subtleties that it
18 matches
Mail list logo
