[ 
https://issues.apache.org/jira/browse/LUCENE-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786541#action_12786541
 ] 

Mark Miller commented on LUCENE-1606:
-------------------------------------

bq. Yeah I tried to do some of this in a very quick way if you look at the 
tests... I generate some random wildcard/regexp queries (mainly to prevent bugs 
from being introduced).

Yeah, I think the tests are pretty solid (from the briefs looks I've had thus 
far) - this is mainly just a precaution - so that we are not surprised by a 
more realistic corpus. And to have the opportunity to compare with the old 
WildcardQuery - I'd rather not keep it around for tests - once we are confident 
its the same (and I am at this point), I'm happy to see it fade into the night. 
Replacing such a core piece though, I want to be absolutely sure everything is 
on the level.

bq, they are definitely contrived but I think cover the bases for any unicode 
problems.

Right - in terms of unit tests, I think you've done great based on what I've 
seen. This is just throwing more variety at a larger more realistic corpus. 
More of a one time deal than something that should be incorporated into the 
tests. Ensures there are no surprises for me - since I didn't write any of this 
code (and I'm not yet super familiar with it), it helps with my comfort level :)

bq. One problem is that none of this unicode stuff is ever a problem on trunk!

Yeah - I assumed not. But as I'm not that familiar with the automaton stuff 
yet, I wanted to be sure there wasn't going to be any input that somehow 
confused it. I realize that your familiarity level probably tells you thats not 
possible - but mine puts me in the position of testing anyway - else I'll look 
like a moron when I +1 this thing ;)

bq. If you save this test setup, 

I'll save it for sure.

> Automaton Query/Filter (scalable regex)
> ---------------------------------------
>
>                 Key: LUCENE-1606
>                 URL: https://issues.apache.org/jira/browse/LUCENE-1606
>             Project: Lucene - Java
>          Issue Type: New Feature
>          Components: Search
>            Reporter: Robert Muir
>            Assignee: Robert Muir
>            Priority: Minor
>             Fix For: 3.1
>
>         Attachments: automaton.patch, automatonMultiQuery.patch, 
> automatonmultiqueryfuzzy.patch, automatonMultiQuerySmart.patch, 
> automatonWithWildCard.patch, automatonWithWildCard2.patch, 
> BenchWildcard.java, LUCENE-1606-flex.patch, LUCENE-1606-flex.patch, 
> LUCENE-1606-flex.patch, LUCENE-1606-flex.patch, LUCENE-1606-flex.patch, 
> LUCENE-1606-flex.patch, LUCENE-1606.patch, LUCENE-1606.patch, 
> LUCENE-1606.patch, LUCENE-1606.patch, LUCENE-1606.patch, LUCENE-1606.patch, 
> LUCENE-1606.patch, LUCENE-1606.patch, LUCENE-1606.patch, LUCENE-1606.patch, 
> LUCENE-1606.patch, LUCENE-1606.patch, LUCENE-1606.patch, 
> LUCENE-1606_nodep.patch
>
>
> Attached is a patch for an AutomatonQuery/Filter (name can change if its not 
> suitable).
> Whereas the out-of-box contrib RegexQuery is nice, I have some very large 
> indexes (100M+ unique tokens) where queries are quite slow, 2 minutes, etc. 
> Additionally all of the existing RegexQuery implementations in Lucene are 
> really slow if there is no constant prefix. This implementation does not 
> depend upon constant prefix, and runs the same query in 640ms.
> Some use cases I envision:
>  1. lexicography/etc on large text corpora
>  2. looking for things such as urls where the prefix is not constant (http:// 
> or ftp://)
> The Filter uses the BRICS package (http://www.brics.dk/automaton/) to convert 
> regular expressions into a DFA. Then, the filter "enumerates" terms in a 
> special way, by using the underlying state machine. Here is my short 
> description from the comments:
>      The algorithm here is pretty basic. Enumerate terms but instead of a 
> binary accept/reject do:
>       
>      1. Look at the portion that is OK (did not enter a reject state in the 
> DFA)
>      2. Generate the next possible String and seek to that.
> the Query simply wraps the filter with ConstantScoreQuery.
> I did not include the automaton.jar inside the patch but it can be downloaded 
> from http://www.brics.dk/automaton/ and is BSD-licensed.

-- 
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-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org

Reply via email to