[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702651#action_12702651
]
Shai Erera commented on LUCENE-1593:
bq. Same for BS2.score() and score(HC) - initCoun
Add next() and skipTo() variants to DocIdSetIterator that return the current
doc, instead of boolean
Key: LUCENE-1614
URL: https://issues.apache.org/jira/browse/L
Hi Guys:
A while ago I posted some enhancements to disjunction and conjunction
docIdSetIterators that showed performance improvements to Lucene-1345. I
think it got mixed up with another discussion on that issue. Was wondering
what happened with it and what are the plans.
Thanks
-John
[
https://issues.apache.org/jira/browse/LUCENE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702649#action_12702649
]
John Wang commented on LUCENE-1613:
---
I understand this is a rather difficult problem to
[
https://issues.apache.org/jira/browse/LUCENE-1613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated LUCENE-1613:
--
Attachment: TestDeleteAndDocFreq.java
Test showing docFreq not updated when there are deletes.
> Term
TermEnum.docFreq() is not updated with there are deletes
Key: LUCENE-1613
URL: https://issues.apache.org/jira/browse/LUCENE-1613
Project: Lucene - Java
Issue Type: Bug
Compon
[
https://issues.apache.org/jira/browse/LUCENE-1612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Wang updated LUCENE-1612:
--
Attachment: lucene-1612-patch.txt
Patch attach with test. Index is not backwards compatible.
> expose
expose lastDocId in the posting from the TermEnum API
-
Key: LUCENE-1612
URL: https://issues.apache.org/jira/browse/LUCENE-1612
Project: Lucene - Java
Issue Type: Improvement
Comp
On Fri, Apr 24, 2009 at 6:20 PM, eks dev wrote:
> just do not forget to use -1 < doc instead of -1 != doc
Perhaps doc >=0 instead of doc != -1?
The crux of it is that status flags (result positive, negative, or
zero) are set by many operations - hence a compare/test operation can
often be elimina
On 4/24/2009 at 6:24 PM, Michael McCandless wrote:
> On Fri, Apr 24, 2009 at 5:44 PM, Steven A Rowe wrote:
> > On 4/24/2009 at 4:45 PM, Michael McCandless wrote:
> > > On Fri, Apr 17, 2009 at 1:46 PM, Steven A Rowe
> > > wrote:
> > > > - Five issues (LUCENE-1186, 1452, 1453, 1465 and 1544) are
>
[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702596#action_12702596
]
Jason Rutherglen commented on LUCENE-1313:
--
I'm confused as to how we make Docume
[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702579#action_12702579
]
Michael McCandless commented on LUCENE-1313:
{quote}
So we're ok with the bloc
[
https://issues.apache.org/jira/browse/LUCENE-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-1610.
Resolution: Fixed
Thanks Steve!
> Preserve whitespace in sections in the Changes
[
https://issues.apache.org/jira/browse/LUCENE-1611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-1611:
---
Attachment: LUCENE-1611.patch
Attached patch to prevent starting new merges after OO
Hi Shai,
absolutely!
we have been there, and there are already some micro benchmarks done in
LUCENE-1345
just do not forget to use -1 < doc instead of -1 != doc, trust me, Yonik
convinced me :)
as a side effect, this change would have some positive effects on iterator
semantics, prevents, ve
On Fri, Apr 24, 2009 at 5:44 PM, Steven A Rowe wrote:
> Hi Mike,
>
> On 4/24/2009 at 4:45 PM, Michael McCandless wrote:
>> On Fri, Apr 17, 2009 at 1:46 PM, Steven A Rowe wrote:
>> > - Five issues (LUCENE-1186, 1452, 1453, 1465 and 1544) are mentioned
>> > in both the 2.4.1 section and in the Trun
[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702573#action_12702573
]
Jason Rutherglen commented on LUCENE-1313:
--
{quote} I think we could adopt a simp
Hi Mike,
On 4/24/2009 at 4:45 PM, Michael McCandless wrote:
> On Fri, Apr 17, 2009 at 1:46 PM, Steven A Rowe wrote:
> > - Five issues (LUCENE-1186, 1452, 1453, 1465 and 1544) are mentioned
> > in both the 2.4.1 section and in the Trunk section. AFAICT, it has
> > not been standard practice to me
It's a nice approach, but I think it relies on C interpreting integer
0 as false, which we can't do in Java. (And, we lack "unsigned int"
in java so we have immense freedom to pick any negative number as our
sentinel ;) ).
Not to mention it'd be a scary change to make at this point! So I
think
Do not launch new merges if IndexWriter has hit OOME
Key: LUCENE-1611
URL: https://issues.apache.org/jira/browse/LUCENE-1611
Project: Lucene - Java
Issue Type: Bug
Components: In
On Sat, Apr 25, 2009 at 12:24:59AM +0300, Shai Erera wrote:
> But I thought doc Ids start with 0? That's why I wrote 'set to -1' ...
This was in the context of KinoSearch. In KS, doc numbers start at 1.
Marvin Humphrey
-
To uns
On Fri, Apr 24, 2009 at 05:18:30PM -0400, Michael McCandless wrote:
> > One additional wrinkle, though: doc nums start at 1 rather than 0, so the
> > return values for Next() and Advance() can double as a booleans.
>
> Meaning they return 0 to indicate "no more docs"?
Yes. 0 is our sentinel.
M
But I thought doc Ids start with 0? That's why I wrote 'set to -1' ...
On Sat, Apr 25, 2009 at 12:18 AM, Michael McCandless <
luc...@mikemccandless.com> wrote:
> On Fri, Apr 24, 2009 at 4:20 PM, Marvin Humphrey
> wrote:
>
> > One additional wrinkle, though: doc nums start at 1 rather than 0, so
[
https://issues.apache.org/jira/browse/LUCENE-1610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated LUCENE-1610:
Attachment: LUCENE-1610.patch
Implements the suggested fix: is converted to (instead of to
<
On Fri, Apr 24, 2009 at 4:20 PM, Marvin Humphrey wrote:
> One additional wrinkle, though: doc nums start at 1 rather than 0, so the
> return values for Next() and Advance() can double as a booleans.
Meaning they return 0 to indicate "no more docs"?
Mike
Preserve whitespace in sections in the Changes.html generated from
CHANGES.txt by changes2html.pl
Key: LUCENE-1610
URL: https://issues.apache.org/jira/browse
On Fri, Apr 17, 2009 at 1:46 PM, Steven A Rowe wrote:
> A few random observations about CHANGES.txt and the generated CHANGES.html:
>
> - The "ü" in Christian Kohlschütter's name is not proper UTF-8 (maybe it's
> double-encoded or something) in the two LUCENE-1186 mentions in the Trunk
> section
[
https://issues.apache.org/jira/browse/LUCENE-831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702526#action_12702526
]
Michael McCandless commented on LUCENE-831:
---
{quote}
Grandma! But yeah we need to
On Fri, Apr 24, 2009 at 10:26:21PM +0300, Shai Erera wrote:
> I think we can make some optimization to DocIdSetIterator. Today, it defines
> next() and skipTo(int) which return a boolean. I've checked the code and it
> looks like almost always when these two are called, they are followed by a
> ca
> George, did you mean LUCENE-1516 below? (LUCENE-1313 is a further
> improvement to near real-time search that's still being iterated on).
>
> In general I would say 2.9 seems to be in rather active development still
> ;)
>
> I too would love to hear about production/beta use of 2.9. George
>
On the "it touches the same code" criteria, I would agree.
On the "it's the same core problem" criteria, I would disagree.
Also I would think this change is simpler than the "isRandomAccess"
addition and so probably would land before isRandomAccess... so I
think I'd lean towards keeping them as s
[
https://issues.apache.org/jira/browse/LUCENE-1252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702520#action_12702520
]
Michael McCandless commented on LUCENE-1252:
Right, I think this is more about
[
https://issues.apache.org/jira/browse/LUCENE-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shon Vella updated LUCENE-1604:
---
Attachment: LUCENE-1604.patch
Updated patch that preserves disableNorms flag across clone and reopen
Maybe combine this with the isRandomAccess change it DocIdSet?
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: Michael McCandless [mailto:luc...@mikemccandless.com]
> Sent: Friday, April 24, 2009 9:46 PM
[
https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved LUCENE-1575.
---
Resolution: Fixed
OK, I resolve the issue again. I was just wondering and wanted to be sure.
[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702515#action_12702515
]
Michael McCandless commented on LUCENE-1313:
bq. I don't think it's necessary
[
https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702509#action_12702509
]
Michael McCandless commented on LUCENE-1575:
bq. Shalin found a backwards-inco
George, did you mean LUCENE-1516 below? (LUCENE-1313 is a further
improvement to near real-time search that's still being iterated on).
In general I would say 2.9 seems to be in rather active development still ;)
I too would love to hear about production/beta use of 2.9. George
maybe you should
I think this is a good idea! I think a new issue is best.
Mike
On Fri, Apr 24, 2009 at 3:26 PM, Shai Erera wrote:
> Hi
>
> I think we can make some optimization to DocIdSetIterator. Today, it defines
> next() and skipTo(int) which return a boolean. I've checked the code and it
> looks like almo
[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702503#action_12702503
]
Michael McCandless commented on LUCENE-1593:
bq. If it equals, it's also rejec
Mark Miller wrote:
Shai Erera wrote:
Hi
I think we can make some optimization to DocIdSetIterator. Today, it
defines next() and skipTo(int) which return a boolean. I've checked
the code and it looks like almost always when these two are called,
they are followed by a call to doc().
I was t
Shai Erera wrote:
Hi
I think we can make some optimization to DocIdSetIterator. Today, it
defines next() and skipTo(int) which return a boolean. I've checked
the code and it looks like almost always when these two are called,
they are followed by a call to doc().
I was thinking that if thos
[
https://issues.apache.org/jira/browse/LUCENE-1313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702496#action_12702496
]
Jason Rutherglen commented on LUCENE-1313:
--
For this patch I'm debating whether t
Hi
I think we can make some optimization to DocIdSetIterator. Today, it defines
next() and skipTo(int) which return a boolean. I've checked the code and it
looks like almost always when these two are called, they are followed by a
call to doc().
I was thinking that if those two returned the doc I
[
https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702488#action_12702488
]
Shai Erera commented on LUCENE-1575:
If you read somewhere above, you'll see that we'v
[
https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler reopened LUCENE-1575:
---
> Refactoring Lucene collectors (HitCollector and extensions)
>
[
https://issues.apache.org/jira/browse/LUCENE-1575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702471#action_12702471
]
Uwe Schindler commented on LUCENE-1575:
---
Hi,
Shalin found a backwards-incompatible c
[
https://issues.apache.org/jira/browse/LUCENE-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702461#action_12702461
]
Michael McCandless commented on LUCENE-1516:
bq. We need an IndexWriter.getMer
[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702448#action_12702448
]
Shai Erera commented on LUCENE-1593:
bq. I think it should work fine, for most types,
[
https://issues.apache.org/jira/browse/LUCENE-1539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702436#action_12702436
]
Michael McCandless commented on LUCENE-1539:
{quote}
Yeah? Ok. So the deleteD
[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702418#action_12702418
]
Michael McCandless commented on LUCENE-1593:
bq. Actually, I think BooleanSco
Please do!
Mike
On Thu, Apr 23, 2009 at 7:13 AM, Varun Dhussa wrote:
> Hi,
>
> I was going through the Levenshtein distance code in
> org.apache.lucene.search.FuzzyTermEnum.java of the 2.4.1 build. I
> noticed that there can be a small, but effective optimization to the
> distance calculation co
Will do.
Michael McCandless wrote:
OK that looks right.
Though, maybe you should add javadocs to FieldValueHitQueue saying it
does *not* do AUTO resolution? (Since we've deprecated FSHQ in favor
of FVHQ, I think we should call out this difference?). And state the
workaround (calling FVHQ.dete
OK that looks right.
Though, maybe you should add javadocs to FieldValueHitQueue saying it
does *not* do AUTO resolution? (Since we've deprecated FSHQ in favor
of FVHQ, I think we should call out this difference?). And state the
workaround (calling FVHQ.detectFieldType yourself)?
Mike
On Fri,
[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702417#action_12702417
]
Michael McCandless commented on LUCENE-1593:
bq. I tried to move to pre-popul
[
https://issues.apache.org/jira/browse/LUCENE-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702404#action_12702404
]
Michael McCandless commented on LUCENE-1609:
If it's only for segment merging,
[
https://issues.apache.org/jira/browse/LUCENE-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702379#action_12702379
]
Yonik Seeley commented on LUCENE-1609:
--
Re: why the lazy load
http://www.lucidimagina
[
https://issues.apache.org/jira/browse/LUCENE-1593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702343#action_12702343
]
Shai Erera commented on LUCENE-1593:
Few updates (it's been long since I posted on thi
You'll do best to direct this question to the Hibernate group. java-
dev is for Lucene development so not an appropriate Lucene place to
ask. java-user would be better, but your question is more Hibernate
specific.
Erik
On Apr 24, 2009, at 3:49 AM, gopalbisht wrote:
Hi all,
I
I'm just putting the auto resolution back in fshq and there is no double
check - foolish me. As I first said, we will either resolve first in
back compat mode and it will be skipped in fshq, or it will be resolved
in fshq for anyone using it externally (and not resolving first on there
own). I'
Eh - we have to spin through all the fields to check for legacy first
anyway. Just doing it twice in legacy mode is probably best? I think
there is no way to avoid spinning through the fields twice in any case
(you have to spin through the sort fields to know you dont want to spin
through the s
Ah, right - thats basically what I was suggesting, though I was thinking
that we might need to resolve twice, but of course your right and we
don't have to. Lucene does still use fshq for back compat (for custom
field source I think?), but I can just do the auto resolution in
IndexSearcher only
Hi all,
I am using hibernate search with lucene. I need to create index of DomainTag
object which have only one composite key. I am unware how to define the
annotations for the composite key in DomainTag (pojo) class.
If any one can help , please help me. Thanks in advance.
My DomainTag.hbm.x
Urgh, right. Can't we simply restore the AUTO resolution into it?
Existing (direct) usage of it must be passing in the top-level
IndexReader. (Lucene doesn't use FSHQ internally).
Mike
On Thu, Apr 23, 2009 at 6:48 PM, Mark Miller wrote:
> Just got off the train and ny to ct has a brilliant bar
64 matches
Mail list logo
