> 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
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
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
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
[ 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
> ---
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
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
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
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://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
[
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'
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
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:
[ 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
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
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
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
: > 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
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
[
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
20 matches
Mail list logo
