You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Michael McCandless (JIRA)" <ji...@apache.org> on 2010/04/07 21:06:33 UTC
[jira] Created: (LUCENE-2383) Some small fixes after the flex
merge...
Some small fixes after the flex merge...
----------------------------------------
Key: LUCENE-2383
URL: https://issues.apache.org/jira/browse/LUCENE-2383
Project: Lucene - Java
Issue Type: Bug
Reporter: Michael McCandless
Assignee: Michael McCandless
Priority: Minor
Fix For: 3.1
Attachments: LUCENE-2383.patch
Changes:
* Re-introduced specialization optimization to FieldCacheRangeQuery;
also fixed bug (was failing to check deletions in advance)
* Changes 2 checkIndex methods from protected -> public
* Add some missing null checks when calling MultiFields.getFields or
IndexReader.fields()
* Tweak'd CHANGES a bit
* Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Resolved: (LUCENE-2383) Some small fixes after the flex
merge...
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless resolved LUCENE-2383.
----------------------------------------
Resolution: Fixed
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2383) Some small fixes after the flex
merge...
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854684#action_12854684 ]
Michael McCandless commented on LUCENE-2383:
--------------------------------------------
Thanks Uwe, I agree that's cleaner -- I'll commit shortly.
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-2383) Some small fixes after
the flex merge...
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854681#action_12854681 ]
Uwe Schindler edited comment on LUCENE-2383 at 4/7/10 8:23 PM:
---------------------------------------------------------------
FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:
{code}
do {
doc++;
if (doc >= maxDoc) return NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}
and the same in advance(), little bit changed:
{code}
for (doc = target; doc < maxDoc; doc++) {
if (!skipDocs.get(doc) && matchDoc(doc))
return doc;
}
return NO_MORE_DOCS;
{code}
The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
was (Author: thetaphi):
FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:
{code}
do {
doc++;
if (doc >= maxDoc) return NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}
and the same in advance(), little bit changed:
{code}
for (int doc= target; doc < maxDoc; doc++) {
if (!skipDocs.get(doc) && matchDoc(doc))
return doc;
}
return NO_MORE_DOCS;
{code}
The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Updated: (LUCENE-2383) Some small fixes after the flex
merge...
Posted by "Michael McCandless (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Michael McCandless updated LUCENE-2383:
---------------------------------------
Attachment: LUCENE-2383.patch
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-2383) Some small fixes after
the flex merge...
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854681#action_12854681 ]
Uwe Schindler edited comment on LUCENE-2383 at 4/7/10 8:24 PM:
---------------------------------------------------------------
FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:
{code}
do {
doc++;
if (doc >= maxDoc)
return doc = NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}
and the same in advance(), little bit changed:
{code}
for (doc = target; doc < maxDoc; doc++) {
if (!skipDocs.get(doc) && matchDoc(doc))
return doc;
}
return doc = NO_MORE_DOCS;
{code}
The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
was (Author: thetaphi):
FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:
{code}
do {
doc++;
if (doc >= maxDoc) return NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}
and the same in advance(), little bit changed:
{code}
for (doc = target; doc < maxDoc; doc++) {
if (!skipDocs.get(doc) && matchDoc(doc))
return doc;
}
return NO_MORE_DOCS;
{code}
The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org
[jira] Commented: (LUCENE-2383) Some small fixes after the flex
merge...
Posted by "Uwe Schindler (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/LUCENE-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12854681#action_12854681 ]
Uwe Schindler commented on LUCENE-2383:
---------------------------------------
FCRF looks ok, I would only change the nextDoc() loop in the deletions-aware iterator to:
{code}
do {
doc++;
if (doc >= maxDoc) return NO_MORE_DOCS;
} while (skipDocs.get(doc) || !matchDoc(doc));
return doc;
{code}
and the same in advance(), little bit changed:
{code}
for (int doc= target; doc < maxDoc; doc++) {
if (!skipDocs.get(doc) && matchDoc(doc))
return doc;
}
return NO_MORE_DOCS;
{code}
The try catch is then unneeded. This seems clearer for me. The non-skipdocs iterator is performanter with the try...catch, as it preserves one bounds check. But we need to do the bounds check here in all cases, why not do up-front?
> Some small fixes after the flex merge...
> ----------------------------------------
>
> Key: LUCENE-2383
> URL: https://issues.apache.org/jira/browse/LUCENE-2383
> Project: Lucene - Java
> Issue Type: Bug
> Reporter: Michael McCandless
> Assignee: Michael McCandless
> Priority: Minor
> Fix For: 3.1
>
> Attachments: LUCENE-2383.patch
>
>
> Changes:
> * Re-introduced specialization optimization to FieldCacheRangeQuery;
> also fixed bug (was failing to check deletions in advance)
> * Changes 2 checkIndex methods from protected -> public
> * Add some missing null checks when calling MultiFields.getFields or
> IndexReader.fields()
> * Tweak'd CHANGES a bit
> * Removed some small dead code
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org