Mailing-List: contact java-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-dev@lucene.apache.org
Message-ID: <613303618.1239718995270.JavaMail.jira@brutus>
Date: Tue, 14 Apr 2009 07:23:15 -0700 (PDT)
From: "Uwe Schindler (JIRA)" <jira@apache.org>
To: java-dev@lucene.apache.org
Subject: [jira] Updated: (LUCENE-1602) Rewrite TrieRange to use
 MultiTermQuery
In-Reply-To: <502476924.1239718515238.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LUCENE-1602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Uwe Schindler updated LUCENE-1602:
----------------------------------

    Attachment: LUCENE-1602.patch

Here the patch:
1. There are some changes to FilterTermEnum in core:
  - Make the private members protected, to have access to them from the very special TrieRangeTermEnum
  - Fix a small inconsistency (docFreq() now only returns a value, if a valid term is existing)
  - All core tests pass

2. TrieRange patch:
  - New TrieRangeQuery classes
  - TrieRangeFilter is now only a wrapper (like in core)
  - The work is done in package-private TrieRangeTermEnum. This was really a fun to implement this: It started with a very large and complicated version that got simplier and simplier at the end. I am really happy with it now. Maybe a extra test for the "special cases" should be added

*Some additional comments:*
The functions that return the unique term count hit during executing query/filter is implemented as a counter in the enum that counts all valid terms in termCompare(). Maybe this information is also interesting for other MultiTermQueries. How about counting this directly in MultiTermQuery for all such queries and export the method there? It would be really nice, to get e.g. the number of terms for a classical range query, to see the improvement. I could patch the MultiTermQuery to do this internally. Any comments about that?

The package and class names are still contrib-like as before. A move to core would rename the classes as discussed.

> Rewrite TrieRange to use MultiTermQuery
> ---------------------------------------
>
>                 Key: LUCENE-1602
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1602
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: contrib/*
>    Affects Versions: 2.9
>            Reporter: Uwe Schindler
>            Assignee: Uwe Schindler
>             Fix For: 2.9
>
>         Attachments: LUCENE-1602.patch
>
>
> Issue for discussion here: http://www.lucidimagination.com/search/document/46a548a79ae9c809/move_trierange_to_core_module_and_integration_issues
> This patch is a rewrite of TrieRange using MultiTermQuery like all other core queries. This should make TrieRange identical in functionality to core range queries.

-- 
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