[
http://issues.apache.org/jira/browse/LUCENE-443?page=comments#action_12331775 ]
Abdul Chaudhry commented on LUCENE-443:
---
ok, this makes sense as the scoring engine runs something like this
while (scorer.next()) {
int doc = scorer.doc();
float sc
Use an open-ended range query by leaving one endpoint null of a RangeQuery
or RangeFilter. The current QueryParser API doesn't have syntax to support
this so you have to use the Java API.
-Yonik
Now hiring -- http://tinyurl.com/7m67g
On 10/10/05, haipeng du <[EMAIL PROTECTED]> wrote:
>
> I want
: > Doesn't this cause a problem for highly interactive and large indexes? Since
: > every update to the index requires the rewriting of the norms, and
: > constructing a new array.
:
: The original complaint was primarily about search-time memory size, not
: update speed. I like the proposed pat
I want to search lucene with some values are greater than specified value.
How could I create a query?
Thanks a lot.
--
Haipeng Du
Software Engineer
Comphealth,
Salt Lake City
Hi,
I have been studying the Lucene indexing code for a bit. I am not sure if I
understand the problem scope completely, but, storing extra information
using TermsInfoWriter may not solve the problem?
For the example of XML document tag depth, could that be a seperate field?
Because Lucene term i
Robert Engels wrote:
Doesn't this cause a problem for highly interactive and large indexes? Since
every update to the index requires the rewriting of the norms, and
constructing a new array.
The original complaint was primarily about search-time memory size, not
update speed. I like the propo
[ http://issues.apache.org/jira/browse/LUCENE-449?page=all ]
Daniel Naber resolved LUCENE-449:
-
Fix Version: 1.9
Resolution: Fixed
Thanks for the patch, it has just been committed.
> NullPointerException when temporary directory not readable
Doesn't this cause a problem for highly interactive and large indexes? Since
every update to the index requires the rewriting of the norms, and
constructing a new array.
How expensive is the maintining of the norms on disk, at least in regards to
index merging?
-Original Message-
From:
Chris Hostetter wrote:
2) Can you think of a clean way for individual applications to eliminate
norms (via subclassing the lucene code base - ie: no patching)
Can't you simply subclass FilterIndexReader and override norms() to
return a cached dummy array of Similarity.encodeNorm(1.0f) f
[
http://issues.apache.org/jira/browse/LUCENE-443?page=comments#action_12331735 ]
paul.elschot commented on LUCENE-443:
-
The score() method can be simplified to use only the 'i' index. There is no need
to offset the index into the scorers with the 'pos'
[ http://issues.apache.org/jira/browse/LUCENE-450?page=all ]
Yonik Seeley updated LUCENE-450:
Attachment: MatchAllDocsQuery_boost.txt
attaching patch to use boost and queryNorm and change explain() to match.
> MatchAllDocsQuery doesn't honor boost or qu
MatchAllDocsQuery doesn't honor boost or queryNorm
--
Key: LUCENE-450
URL: http://issues.apache.org/jira/browse/LUCENE-450
Project: Lucene - Java
Type: Bug
Components: Search
Versions: CVS Nightly - Specify date
http://wiki.apache.org/jakarta-lucene/Lucene2Whiteboard
See item #11 of API changes. Maybe along the lines of what you are
interested in, although I don't know if anyone has even attempted a design
of it. I would also like to see this, plus the ability to store info at
higher levels in the Inde
Lucene does "docment-at-a-time", as you describe. One could make a query to
do term-at-a-time in lucene if desired, as the traversal logic is
encapsulated in the particular scorers for queries.
> I'm looking into how easy it would be to implement a streaming search in
Lucene
> (where a document is
Hi,
To the best of my knowledge, it is not possible to add generic data to a
Term's posting list.
By this I mean info that is defined by the search engine, not Lucene itself.
Whereas Lucene adds some data to the posting lists, such as the term's
position within a document,
there are many other use
[ http://issues.apache.org/jira/browse/LUCENE-435?page=all ]
Lukas Zapletal updated LUCENE-435:
--
Attachment: writeBytes.patch
Fixed patch, TestStore also updated...
> [PATCH] BufferedIndexOutput - optimized writeBytes() method
> ---
On Oct 10, 2005, at 5:35 AM, Shane O'Sullivan wrote:
Are the new features of Lucene 1.9 documented anywhere? I couldn't
find it
on the site.
All major changes are logged to CHANGES.txt:
http://svn.apache.org/repos/asf/lucene/java/trunk/CHANGES.txt
Also, is there a documented roadmap f
Hi all,
Does Lucene use Document and a time (DAAT), or Term at a time (TAAT)
searching?
To explain what I'm asking, let's look at a three-term query T1 T2 T3
In term-at-a-time (TAAT) evaluation, the engine would typically start by
scanning the entire postings list of T1, and would keep some score
Hi,
Are the new features of Lucene 1.9 documented anywhere? I couldn't find it
on the site.
Also, is there a documented roadmap for Lucene?
Thanks
Shane
> I don't in general disagree with this sort of optimization, but I think
> a good fix is a bit more complicated than what you posted.
Hi Doug, I had some time to redo my fixes...
> This forces a flush() each time a byte array of any size is written.
> That could be much slower when lots of sma
20 matches
Mail list logo
