[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2814:
Attachment: LUCENE-2814.patch
First iteration.
Passes all tests except TestNRTThreads
[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12972298#action_12972298
]
Earwin Burrfoot commented on LUCENE-2814:
-
So, what's the plan?
stop writing
[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12972316#action_12972316
]
Earwin Burrfoot commented on LUCENE-2814:
-
Instead of you pulling out docstore
[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2814:
Attachment: LUCENE-2814.patch
Patch updated to trunk, no nocommits, no *.closeDocStore
[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971248#action_12971248
]
Earwin Burrfoot commented on LUCENE-2814:
-
bq. We should verify the back-compat
[
https://issues.apache.org/jira/browse/LUCENE-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971303#action_12971303
]
Earwin Burrfoot commented on LUCENE-2811:
-
I think SegmentInfo.hasVectors should
[
https://issues.apache.org/jira/browse/LUCENE-2811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971510#action_12971510
]
Earwin Burrfoot commented on LUCENE-2811:
-
From IRC:
SegmentMerger.hasVectors
[
https://issues.apache.org/jira/browse/LUCENE-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971057#action_12971057
]
Earwin Burrfoot commented on LUCENE-2814:
-
I'll take this. I think.
stop writing
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971058#action_12971058
]
Earwin Burrfoot commented on LUCENE-2611:
-
[quote]
bq. I wonder if several .iml
[
https://issues.apache.org/jira/browse/LUCENE-2611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12971058#action_12971058
]
Earwin Burrfoot edited comment on LUCENE-2611 at 12/13/10 5:36 PM
[
https://issues.apache.org/jira/browse/LUCENE-2802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12968503#action_12968503
]
Earwin Burrfoot commented on LUCENE-2802:
-
Patch looks cool.
DirectoryReader
[
https://issues.apache.org/jira/browse/LUCENE-2799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966865#action_12966865
]
Earwin Burrfoot commented on LUCENE-2799:
-
I think it's always best to copy-paste
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966550#action_12966550
]
Earwin Burrfoot commented on LUCENE-2790:
-
Ok, let's commit?
There's no need
Actually, in trunk IW doesn't break on anything else.
There's one private no-longer-used method I forgot to delete on my
drop-all-deprecations spree.
And there's a block in addIndexes, that explicitly checks instanceof,
and only then casts to LMP.
I'm against consolidating MP and LMP. MP is a
Hmm .. now that I look closely at it, MP has useCompundFile/DocStore
methods, and LMP just adds getUseCompoundFile(). Why?
And IndexWriter.addIndexes(IndexReader...) queries instanceof LMP, instead
of calling mp.useCompoundFile()?
getUseCompoundFile - is a setting on LMP.
MP.useCompoundFile
On Thu, Dec 2, 2010 at 14:19, Shai Erera ser...@gmail.com wrote:
You can't remove it on 3x, it's used by a host of deprecated methods
that access LMP's settings through IW.
Remove means deprecate in 3x and remove in trunk. Should have been more
clear about that.
We can drop it from trunk
[
https://issues.apache.org/jira/browse/LUCENE-2789?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966071#action_12966071
]
Earwin Burrfoot commented on LUCENE-2789:
-
I'd like to a see a switch like
On Thu, Dec 2, 2010 at 15:04, Shai Erera ser...@gmail.com wrote:
Earwin:
LogMergePolicy.getUseCompoundFile() is a public and not private API on
trunk, not deprecated and used. Perhaps you are talking about something
else?
I was speaking of getLogMergePolicy that you mentioned:
1) Fix IW to
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966103#action_12966103
]
Earwin Burrfoot commented on LUCENE-2790:
-
Fails addIndexesWithThreads
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966108#action_12966108
]
Earwin Burrfoot edited comment on LUCENE-2790 at 12/2/10 8:12 AM
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2790:
Attachment: LUCENE-2790.patch
Check this patch out.
It moves noCFS ratio
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966112#action_12966112
]
Earwin Burrfoot commented on LUCENE-2790:
-
bq. I checked who implements
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2790:
Attachment: LUCENE-2790.patch
Okay, this patch fixes remaining threading issue
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2790:
Attachment: LUCENE-2790.patch
Fixed your test failure
IndexWriter should call
[
https://issues.apache.org/jira/browse/LUCENE-2790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966285#action_12966285
]
Earwin Burrfoot commented on LUCENE-2790:
-
Shai, what about:
bq. My only concern
[
https://issues.apache.org/jira/browse/LUCENE-2307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot closed LUCENE-2307.
---
Resolution: Cannot Reproduce
Never reproduced since, closing as stale and outdated
[
https://issues.apache.org/jira/browse/LUCENE-2471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12966358#action_12966358
]
Earwin Burrfoot commented on LUCENE-2471:
-
Hmmm. Are we going to do
I agree with Robert that minimizing analysis - indexer interface is
the way to go.
For me, one of Lucene's problems is that it wants to do too much stuff
out of the box, and is tightly coupled, so you can't drop much of the
things you never need.
Having minimal interface for the indexer allows us
On Tue, Nov 30, 2010 at 07:48, Shai Erera ser...@gmail.com wrote:
The break was only in MockRAMDir, and even
that is because I changed fileMap type from HashMap to Map, which IMO should
have been defined like that from the beginning.
As a piece of trivia.
I did some benchmarks and declaring
We can try writing tests that only check binary compatibility for
public/protected members?
And use these for back-compat testing.
On Tue, Nov 30, 2010 at 12:47, Shai Erera ser...@gmail.com wrote:
I realize the benefits of not storing the backwards source -- I don't care
too much about the size
Oh, Shai already said this, so +1.
On Tue, Nov 30, 2010 at 13:11, Earwin Burrfoot ear...@gmail.com wrote:
We can try writing tests that only check binary compatibility for
public/protected members?
And use these for back-compat testing.
On Tue, Nov 30, 2010 at 12:47, Shai Erera ser
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965194#action_12965194
]
Earwin Burrfoot commented on LUCENE-2779:
-
bq. Cloning the keySet
[
https://issues.apache.org/jira/browse/LUCENE-2785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965202#action_12965202
]
Earwin Burrfoot commented on LUCENE-2785:
-
A Collector, that counts - priceless
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965296#action_12965296
]
Earwin Burrfoot commented on LUCENE-2779:
-
Quoting Sun JDK 1.6:
{code}
public
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12965380#action_12965380
]
Earwin Burrfoot commented on LUCENE-2779:
-
bq. So I ended up writing the following
On Mon, Nov 29, 2010 at 13:34, Robert Muir rcm...@gmail.com wrote:
On Mon, Nov 29, 2010 at 2:50 AM, Earwin Burrfoot ear...@gmail.com wrote:
And for indexes:
* Index compatibility is guaranteed across two adjacent major
releases. eg 2.x - 3.x, 3.x - 4.x.
That includes both binary compat
. And for
that the factories are needed.
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Earwin Burrfoot [mailto:ear...@gmail.com]
Sent: Monday, November 29, 2010 11:53 AM
To: dev@lucene.apache.org
Subject: Re
I'm talking about the analyzers we provide in lucene itself.
there is no reason, no advantage towards these being .java code: it
just causes problems.
I see little difference between
public class StockAnalyzers {
public static final Analyzer STANDARD_30 = new AnalyzerBuilder().
add(new
On Mon, Nov 29, 2010 at 15:28, Robert Muir rcm...@gmail.com wrote:
On Mon, Nov 29, 2010 at 7:21 AM, Earwin Burrfoot ear...@gmail.com wrote:
There's no reason, no advantage towards using .xml files for
configuration, when said configuration can easily be expressed
programmatically. It just
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964749#action_12964749
]
Earwin Burrfoot commented on LUCENE-2781:
-
bq. unfortunately we cant yet remove
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964751#action_12964751
]
Earwin Burrfoot commented on LUCENE-2781:
-
Hmm.. and regarding this exact case
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964755#action_12964755
]
Earwin Burrfoot commented on LUCENE-2781:
-
Ok, restore it then and fix deprecation
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964920#action_12964920
]
Earwin Burrfoot commented on LUCENE-2779:
-
I don't believe cloning the keySet
On Mon, Nov 29, 2010 at 20:51, DM Smith dmsmith...@gmail.com wrote:
The other thing I'd like is for the spec to be save along side of the index
as a manifest. From earlier threads, I can see that there might need to be
one for writing and another for reading. I'm not interested in using it to
Or you can make threadlocal RNGs.
On Mon, Nov 29, 2010 at 23:20, Yonik Seeley yo...@lucidimagination.com wrote:
On Mon, Nov 29, 2010 at 2:52 PM, Michael McCandless
luc...@mikemccandless.com wrote:
Though why doesn't the random seed reproduce it?
OK, I think I see why.
For reproducibility,
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964982#action_12964982
]
Earwin Burrfoot commented on LUCENE-2779:
-
Maybe we should commit it to 4.0 only
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964511#action_12964511
]
Earwin Burrfoot commented on LUCENE-2779:
-
If you don't write, you don't care
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964512#action_12964512
]
Earwin Burrfoot commented on LUCENE-2779:
-
I mean, even if aquiring locks costed
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964515#action_12964515
]
Earwin Burrfoot commented on LUCENE-2779:
-
My primary point was that you're
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964556#action_12964556
]
Earwin Burrfoot commented on LUCENE-2779:
-
I'm happy with CHM.
The only thing
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12964640#action_12964640
]
Earwin Burrfoot commented on LUCENE-2781:
-
bq. i thought you said you weren't
optimize your 3.x indexes when going through 4.x to 5.x.
On Mon, Nov 29, 2010 at 05:35, Robert Muir rcm...@gmail.com wrote:
On Sat, Nov 27, 2010 at 3:44 PM, Earwin Burrfoot ear...@gmail.com wrote:
I think we should deprecate and remove Version constants as Lucene
progresses?
well one idea
I think we should deprecate and remove Version constants as Lucene progresses?
Imagine there's a number of features in 4.x that get deprecated and
un-defaulted in 5.x, then removed in 6.x
Our user compiled with Version.4_0, it was cool in 4.x, then it still
worked in 5.x, as we preserved index
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2781:
Attachment: drop-deprecations.patch
New patch. Current status:
* Lucene's deprecations
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2781:
Attachment: drop-deprecations.patch
New patch.
Version 2x dropped, 3x deprecated. Builds
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2781:
Attachment: drop-deprecations.patch
Same, rebased on latest trunk.
Drop deprecations
[
https://issues.apache.org/jira/browse/LUCENE-2781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2781:
Attachment: drop-deprecations.patch
Stab one.
Everything works, except Solr - this fails
[
https://issues.apache.org/jira/browse/LUCENE-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935755#action_12935755
]
Earwin Burrfoot commented on LUCENE-2506:
-
bq. Some better Filter API is required
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935794#action_12935794
]
Earwin Burrfoot commented on LUCENE-2691:
-
{quote}
bq. You're still okay
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935813#action_12935813
]
Earwin Burrfoot commented on LUCENE-2779:
-
Using RWLock is needless.
synchronized
[
https://issues.apache.org/jira/browse/LUCENE-2779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935816#action_12935816
]
Earwin Burrfoot commented on LUCENE-2779:
-
In fact, uncontended synchronized block
be a proxy and notify it of anything else besides opening and
closing files. Proxying can be completely transparent.
On Thu, Nov 25, 2010 at 6:00 PM, Earwin Burrfoot (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/LUCENE-2691?page
[
https://issues.apache.org/jira/browse/LUCENE-2506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935899#action_12935899
]
Earwin Burrfoot commented on LUCENE-2506:
-
bq. we are doing an SQL query, get back
Drop deprecations from trunk
Key: LUCENE-2781
URL: https://issues.apache.org/jira/browse/LUCENE-2781
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Earwin Burrfoot
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935400#action_12935400
]
Earwin Burrfoot commented on LUCENE-2755:
-
bq. Refactor IW, MS and MP so that MS
[
https://issues.apache.org/jira/browse/LUCENE-2691?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12935569#action_12935569
]
Earwin Burrfoot commented on LUCENE-2691:
-
You're still okay with an API
[
https://issues.apache.org/jira/browse/LUCENE-2771?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12934078#action_12934078
]
Earwin Burrfoot commented on LUCENE-2771:
-
SegmentReader and AllOtherReaders
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932864#action_12932864
]
Earwin Burrfoot commented on LUCENE-2755:
-
{quote}
If we proceed w/ your proposal
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932561#action_12932561
]
Earwin Burrfoot commented on LUCENE-2755:
-
Shai:
bq. The thing is - the second
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932124#action_12932124
]
Earwin Burrfoot commented on LUCENE-2755:
-
Whatever solution for block-on-add you
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932200#action_12932200
]
Earwin Burrfoot commented on LUCENE-2755:
-
bq. There was some reason why
[
https://issues.apache.org/jira/browse/LUCENE-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932207#action_12932207
]
Earwin Burrfoot commented on LUCENE-1799:
-
.. and not the Codec, as was suggested
[
https://issues.apache.org/jira/browse/LUCENE-1799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932206#action_12932206
]
Earwin Burrfoot commented on LUCENE-1799:
-
Returning to this issue, right now
[
https://issues.apache.org/jira/browse/LUCENE-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12932266#action_12932266
]
Earwin Burrfoot commented on LUCENE-2755:
-
bq. But then you accumulate too many
[
https://issues.apache.org/jira/browse/LUCENE-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929587#action_12929587
]
Earwin Burrfoot commented on LUCENE-2167:
-
bq. No thanks, i dont want to read my
[
https://issues.apache.org/jira/browse/LUCENE-2167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12929407#action_12929407
]
Earwin Burrfoot commented on LUCENE-2167:
-
bq. Would it somehow be possible
It's okay, trunk has iteration-based filters.
Filters with low selectivity might be faster if used in oldstyle
random-access way, though. If one wants to exploit this, compressed
bitmaps are no go.
On Sat, Nov 6, 2010 at 00:29, Peter Karich peat...@yahoo.de wrote:
And they're not
On Fri, Oct 29, 2010 at 21:50, Robert Muir rcm...@gmail.com wrote:
I was suggesting that mathematically, the empty term makes no sense in
an inverted index, and we shouldn't allow it.
Its one solution.
Mathematically an inverted index is keyed by strings. Any strings.
Empty term is just a case
I'd say support them everywhere, and slip LengthFilter into all the
standard Analyzers, so people won't hit empty terms unless they opt-in
for it.
This is a most consistent approach.
On Sat, Oct 30, 2010 at 15:06, Robert Muir rcm...@gmail.com wrote:
On Sat, Oct 30, 2010 at 7:01 AM, Earwin
On Sat, Oct 30, 2010 at 18:49, Uwe Schindler u...@thetaphi.de wrote:
In my opinion, we should not have analyzers at all (just my personal
opinion). new Field(name, TokenStream) is much enough from consistency
standpoint!
Indeed, my friend!
--
Kirill Zakharenko/Кирилл Захаренко
Thread-per-segment approach should run well with Zoie MergePolicy.
On Tue, Sep 28, 2010 at 16:17, Michael McCandless
luc...@mikemccandless.com wrote:
This is an excellent idea!
And, desperately needed.
It's high time Lucene can take advantage of concurrency when running a
single query.
IMHO, Instantiated sucks GC-wise. Put more docs in it, do enough
queries, and RAMDir eventually outperforms it.
On Thu, Aug 26, 2010 at 11:24, Li Li fancye...@gmail.com wrote:
I have about 70k document, the total indexed size is about 15MB(the
orginal text files' size).
dir=new
you mean that InstantiatedIndex is not as fast as its document says?
2010/8/26 Earwin Burrfoot ear...@gmail.com:
IMHO, Instantiated sucks GC-wise. Put more docs in it, do enough
queries, and RAMDir eventually outperforms it.
On Thu, Aug 26, 2010 at 11:24, Li Li fancye...@gmail.com wrote:
I
[
https://issues.apache.org/jira/browse/LUCENE-2593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12897325#action_12897325
]
Earwin Burrfoot commented on LUCENE-2593:
-
Yeehaw! This looks very much like a bug
I believe I've seen a similar condition a few times.
A segments file referring zero-length segment files after a disk full event.
On Fri, Jul 9, 2010 at 13:37, Michael McCandless
luc...@mikemccandless.com wrote:
I responded on the original thread.
Disk full should never cause index corruption
Lies, lies, lies :)
I mean, Sun JIT is overrelied on. Especially in regards to inlining.
But, there are some cases when you can trust it. I.e. if you call a
virtual method and this exact call-site gets refs to different objects
at runtime (meaning here - you wrap different Queries in your
Can we represent the Query
state in some general structure, that no matter which Query you get, you'll
know how to score it?
No. You could go for unified interface that allows you to express
different query states, like a set of untyped key-values, but you'll
end up switching on these
the best way to achieve that.
Shai
On Wed, Jun 9, 2010 at 2:24 PM, Earwin Burrfoot ear...@gmail.com wrote:
Can we represent the Query
state in some general structure, that no matter which Query you get,
you'll
know how to score it?
No. You could go for unified interface that allows you
On Wed, Jun 9, 2010 at 15:39, Doron Cohen cdor...@gmail.com wrote:
I think you'd still not modify a nicely extendible/wrapable API just to
avoid the extra call, unless benchmarking shows that the cost is high.
Current Query API is NOT nicely extensible :)
Look above for BM25BooleanQuery
The problem with your proposal is that, currently, Lucene uses current
iteration state to compute score.
I.e. it already knows which of SHOULD BQ clauses matched for current
doc, so it's easier to calculate the score.
If you change API to allow scoring arbitrary documents (even those
that didn't
Shai, his wrapper Scorer will just look like:
DISI getDISI() {
return delegate.getDISI();
}
float score(int doc) {
return calcMyAwesomeScore(doc);
}
this saves delegate.nextDoc(), delegate.advance() indirection calls.
But I already offered a better alternative :)
On Tue, Jun 8, 2010 at
, Earwin Burrfoot ear...@gmail.com wrote:
To compute a score you have to see which of your subqueries did not
match, which did, and what are the docfreqs/positions for them.
When iterating, and calling score() only for current doc - parts of
this data (maybe even all of it, not sure) is already
[
https://issues.apache.org/jira/browse/LUCENE-2491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12876203#action_12876203
]
Earwin Burrfoot commented on LUCENE-2491:
-
Or we can force the same Codec
[
https://issues.apache.org/jira/browse/LUCENE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12874634#action_12874634
]
Earwin Burrfoot commented on LUCENE-2311:
-
bq. Does your pending patch (what's
[
https://issues.apache.org/jira/browse/LUCENE-2485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12874650#action_12874650
]
Earwin Burrfoot commented on LUCENE-2485:
-
bq. As long as warming a new segment
[
https://issues.apache.org/jira/browse/LUCENE-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873465#action_12873465
]
Earwin Burrfoot commented on LUCENE-2480:
-
Wow! So fast! :)
bq. You didn't remove
[
https://issues.apache.org/jira/browse/LUCENE-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873469#action_12873469
]
Earwin Burrfoot commented on LUCENE-2480:
-
bq. Strange, there were lines in my
[
https://issues.apache.org/jira/browse/LUCENE-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12873292#action_12873292
]
Earwin Burrfoot commented on LUCENE-2480:
-
Doing that now, plus some additions
[
https://issues.apache.org/jira/browse/LUCENE-2480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Earwin Burrfoot updated LUCENE-2480:
Comment: was deleted
(was: Doing that now, plus some additions to Shai's patch)
Remove
I disagree about time limiting MS. It may not be useful in many cases,
true. But I have a scenario in which machines are used to perform all
sorts of tasks and the are windows in which I'm allowed to do 'heavy
operations'.
It's true I can just choose not to merge large segments, but I
101 - 200 of 652 matches
Mail list logo
