search

apache / lucene

Apache Lucene open-source search software
https://lucene.apache.org/
Apache License 2.0
2.6k stars 1.01k forks source link

NumericRange support for new query parser [LUCENE-1768] #2842

Closed asfimport closed 13 years ago

asfimport commented 15 years ago

It would be good to specify some type of "schema" for the query parser in future, to automatically create NumericRangeQuery for different numeric types? It would then be possible to index a numeric value (double,float,long,int) using NumericField and then the query parser knows, which type of field this is and so it correctly creates a NumericRangeQuery for strings like "[1.567..*]" or "(1.787..19.5]".

There is currently no way to extract if a field is numeric from the index, so the user will have to configure the FieldConfig objects in the ConfigHandler. But if this is done, it will not be that difficult to implement the rest.

The only difference between the current handling of RangeQuery is then the instantiation of the correct Query type and conversion of the entered numeric values (simple Number.valueOf(...) cast of the user entered numbers). Evenerything else is identical, NumericRangeQuery also supports the MTQ rewrite modes (as it is a MTQ).

Another thing is a change in Date semantics. There are some strange flags in the current parser that tells it how to handle dates.

Migrated from LUCENE-1768 by Uwe Schindler (@uschindler), resolved Sep 08 2011 Attachments: TestNumericQueryParser-fix.patch (versions: 4), week1.patch, week11-13_for_lucene_3x.patch (versions: 2), week-14.patch, week15_for_lucene_3x.patch, week15_for_trunk.patch, week2.patch, week3.patch, week4.patch, week5-6.patch, week-7.patch, week-8.patch Linked issues:

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

This patch includes the builder for numeric range queries. This week I intend to start writing junits.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

This patch includes code from week 5 and 6. Sorry for taking so long to submit a new patch, but I was hitting many problems when I finally started run the junits.

I updated my workspace and got the new changes which use NumericField to add numeric fields to Documents. So I adapted my junits to that and also refactored some code to use NumericField.DataType in NumericConfig, instead of using Class<? extends Number> when specifying the NumericConfig type.

I added a junit class (TestNumericQueryParser). I reused some LuceneTestCase methods, mainly the ones that generate random things. I took sometime to get where I wanted, I was hitting many problems when using dates in range. In the end, I liked the way the junit is running, inputs are very random, mainly the date formats, using randomly different format styles and locale. I ran the junit in a loop 1000 times and I got no error, so I think it's pretty stable now. Uwe, please, take a look and let me know what you think about it.

testInclusiveLowerRangeQuery and testInclusiveUpperRangeQuery are commented since I found that StandardQueryParser is not supporting mixed include syntaxes, such as {1 TO 2]. Shouldn't it be supported? I don't see why not.

Also, the query parser is not supporting open ended range queries, such as [... to 3].

I am checking "Grant license to ASF for inclusion in ASF works (as per the Apache License §5)" now, because I think the patch is finally ready to be checked in. I ran Lucene top level ant and it finished successfully.

I will work on creating javadocs now.

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

testInclusiveLowerRangeQuery and testInclusiveUpperRangeQuery are commented since I found that StandardQueryParser is not supporting mixed include syntaxes, such as {1 TO 2]. Shouldn't it be supported? I don't see why not.

I will take a look into it, thanks for reporting it, this might really be a bug ;)

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

Hi,

I committed the first patch from #4053 and it changed completely the queryparser config API.

It seems Vinicius is ahead of schedule with this project, is that corret?! Is there anything else to do after documentation? If not, I would ask whether it's possible for you to change the way you use config API for numeric. I think it will not require a lot of change, the api is much simpler now. I can ask Phillipe to help you and explain how the new api works ;) Otherwise, Uwe will not be able to commit your patch, since there will be many classes missing now.

What do you think Uwe?

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Hi Adriano,

I will also review the patch today (using older trunk rev) and then respond.

I think, Vinicius should help with updating the code to the latest config API version which was committed. This is where "community" in this project gets involved. Maybe the other GSoC student and Vinicius should work together to get this solved.

Next week the mid-term evaluations will come, so we should have something to work on this issue except documentation for the second half.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I downgraded my trunk checkout to rev. 1142861 and applied the patch. All tests pass, so nice work until now. The problem is that I am no longer able to commit the patch, as rev. 1142862 was committed before, changing the QP config API, so how to proceed?

Vinicius, how do you want to proceed, are you planning to rewrite the stuff related to #4053?

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Uwe,

I talked to Phillipe about the new API, it does not look complicated. I will try to do the change and submit a new patch by the end of this week, then we can finally have something checked in \o/

Next things do to then: -fix config -write javadocs -write wiki/tutorial explaining how to use query parser with numeric fields

Something else you have in mind Uwe that we can add to the above list? Maybe fix the range query in contrib queryparser which I mentioned in my past comments above. (Have you verified the bug Adriano?)

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I think the "bug" in Contrib QP is there because it's also a bug in Lucene's Core QP (the default impl just emulates core's QP). But in my opinion, it should have separate include/exclude for both limits, so a query like {1 TO 2] should behave as expected.

The QP should in my opinion also support open-ended ranges. The syntax by NumericRangeQuery's toString() is by using stars (this is also what Solr's QP does). For numeric fields, half open ranges are important, as it supports queries like "price <2.00 Dollar". Wasn't there not also an issue open to support other syntax for numerics like > and < operators?

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I have some small things (maybe I will extend this comment when i review more of the code):

This is all for now, more may be added tomorrow.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Uwe,

>>>I think the "bug" in Contrib QP is there because it's also a bug in Lucene's Core QP (the default impl just emulates core's QP). But in my opinion, it should have separate include/exclude for both limits, so a query like {1 TO 2] should behave as expected.

I think the same way, no idea why it's not supporting {1 TO 2]. I can try to fix it, but not sure how long it will take, haven't looked at the code yet. Anyway, it shouldn't be that hard, since core QueryParser is already working the way we expect, we need somehow to copy the same behavour to contrib queryparser.

>>>in NumericRangeQueryNodeBuilder, i would use switch statement on the NumericField.DataType and throw a UnsupportedEx if an unknown type is hit. I want to do this, because there is already an issue open to extend NumericField and NumericRangeQuery by BYTE and SHORT. If we add those types, the code gets unpredictable. With a switch statement and a exception in the defalt clause, it fails predicatable. You should also add similar "default" statement throwing exceptions in all switch statements on this enum type (in general it is good code style to do this).

Agreed! I will do the change.

>>>The current code always handles Date as Long (like Solr does). I am not sure, if this would always be the best idea (see e.g. Lucene In Action book). Maybe we should add a possibility to override the conversion Date <-> Number at a central place to customize? One of the reasons to not support direkt DateRangeQueries was to make the representation of Dates as Numbers open to the user.

Do you mean that Date could return some other type other than LONG? Like INT?! I could add a new parameter to NumberDateFormat that will receive NumeridField.DataType, this way the code could parse the date to the expected number type.

>>> Method "NumericField.DataType getNumericDataType(Number number)": I would use instanceOf checks (as all Number subclasses are final, this is fine and correct). They should be faster than this reflection code.

I will change that as well.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

>>>The current code always handles Date as Long (like Solr does). I am not sure, if this would always be the best idea (see e.g. Lucene In Action book). Maybe we should add a possibility to override the conversion Date <-> Number at a central place to customize? One of the reasons to not support direkt DateRangeQueries was to make the representation of Dates as Numbers open to the user.

Do you mean that Date could return some other type other than LONG? Like INT?! I could add a new parameter to NumberDateFormat that will receive NumeridField.DataType, this way the code could parse the date to the expected number type.

In general, the formatting of a Date to a Number should be possible to customize (e.g. if you only want to format the Date without the time and your index supports only Int dates, like number of days).

I talked to Phillipe about the new API, it does not look complicated. I will try to do the change and submit a new patch by the end of this week, then we can finally have something checked in \o/

That communication should be done in public...

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

>>> In general, the formatting of a Date to a Number should be possible to customize (e.g. if you only want to format the Date without the time and your index supports only Int dates, like number of days).

That's possible, the user just need to provide a NumberFormat that will convert String to whatever Number object the user wants.

asfimport commented 13 years ago

Chris Male (migrated from JIRA)

Hey,

In the next week or so I'm going to want to move this QueryParser, along with the contents of contrib/queryparser, to the new consolidated queryparser module. Is this going to get in the way of the work here?

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

Hi Chris,

If you are just moving code, I think it's fine, at max we will need to rename the paths in the patch to match the new file structure.

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

For numeric fields, half open ranges are important, as it supports queries like "price <2.00 Dollar". Wasn't there not also an issue open to support other syntax for numerics like > and < operators?

Yes, there is, just do not recall the JIRA number now. Maybe Vinicius could try to implement it as well to fill out his task list in case he finishes his tasks before schedule, since it is also related to numeric queries. I am just not sure how much complex the task would be, I know the big change for this is in the syntax parser, which will require to know how to change javacc files.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

This patch includes the fix for the new config api and all changes suggested by Uwe.

Uwe, you should be able to commit it now, I checked out the trunk and applied the patch myself and everything is working fine.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Hi Vinicius, cool thanks! Patched, works - nothing to complain about.

I think I will commit this soon, so your partner from #4053 can also coordinate with you (which was also committed).

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Committed to Lucene trunk revision: 1144744 You can now start and improve the documentation, tests,... Please use current trunk as basis.

One note: I have still seen some switch statements without a default while reviewing.

We should also decide together with #4053 if we should backport this stuff to 3.x (once finished). Adriano?

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I had to fix a javadoc warning, breaking the Jenkins Builds: rev 1144755

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

Hi Uwe,

There are plans to backport #4053 to 3.x, Phillipe is already working on it, still evaluating if it will be possible.

I am not sure about numeric support, Vinicius changed TermRangeQueryNode inheritance, which breaks the backwards compatibility. I am not saying the change is bad, I agree with the new structure, however Vinicius will need to find another solution before backporting it to 3.x.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Vinicius, do you have any plans about backporting the stuff to Lucene 3.x - it should not be that hard :-)

I am not sure about numeric support, Vinicius changed TermRangeQueryNode inheritance, which breaks the backwards compatibility. I am not saying the change is bad, I agree with the new structure, however Vinicius will need to find another solution before backporting it to 3.x.

I am not sure if this is really a break when you change inheritance. If code still compiles, its no break, if classes were renamed its more serious. I am not sure, if implementation classes (and -names) should be covered by the backwards compatibility. In my opinion, mainly the configuration and interfaces of the QP must be covered by backwards policy.

As we are now at mid-time, it would be a good idea, to maybe add some extra syntax support for numerics, like "<" and ">"? We should also add tests/support for half-open ranges, so syntax like "[- TO 1.0]" should also be supported (I am not sure, if TermRangeQueryNode supports this, but numerics should do this in all cases) - the above syntax is also printed out on NumericRangeQuery.toString(), if one of the bounds is null. The latter could be easily implemented by checking for "*" as input to the range bounds and map those special "values" to NULL. Adding support for "<" and ">" (also "<=", ">=") needs knowledge of JavaCC parser language. Vinicius, have you ever worked with JavaCC, so do you think you will be able to extend the syntax?

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

I am not sure if this is really a break when you change inheritance. If code still compiles, its no break, if classes were renamed its more serious. I am not sure, if implementation classes (and -names) should be covered by the backwards compatibility. In my opinion, mainly the configuration and interfaces of the QP must be covered by backwards policy.

I didn't see any class renaming, I need to double check Vinicius's patches. But he did change the query node inheritance, which may affect how processors and builder (specially QueryNodeTreeBuilder) work. I am not saying it is not possible to implement his approach on 3.x, but he will need to deal differently with query nodes classes he created. As I said before, what he did is good and clean, I like the way it is, but it will break someone's code if pushed to 3.x. So if you ask me whether to push it to 3.x, I say YES, just make sure to not break the query node structure that people may be relying on.

As we are now at mid-time, it would be a good idea, to maybe add some extra syntax support for numerics, like "<" and ">"? We should also add tests/support for half-open ranges, so syntax like "[- TO 1.0]" should also be supported (I am not sure, if TermRangeQueryNode supports this, but numerics should do this in all cases) - the above syntax is also printed out on NumericRangeQuery.toString(), if one of the bounds is null. The latter could be easily implemented by checking for "*" as input to the range bounds and map those special "values" to NULL. Adding support for "<" and ">" (also "<=", ">=") needs knowledge of JavaCC parser language. Vinicius, have you ever worked with JavaCC, so do you think you will be able to extend the syntax?

I still need to investigate the bugs Vinicius reported (should have been created a JIRA for that already), I never really tried open ranges in contrib QP. And if Vinicius thinks he will have time and skills to do the JAVACC change to support those new operators, go for it! And remember Vinicius, you don't need to do everything during gsoc, you are always welcome to contribute code whenever you want :)

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Thanks for committing the patch Uwe!

I will review the code again looking for switch without default case and fix it.

I never did anything with javacc, I just quickly looked at the code, does not seem complicated, however, I have no idea how complex is to run javacc and regenerate the java files. Does lucene ant script do that automaticaly?

I can try to fix open range queries on contrib query parser, add "<="-like operators or backport numeric support to 3.x. Just let me know the priorities and I will work on it. My suggestion is that the bug on open range queries is the most critical now, so I could start working on that. Your call Uwe.

asfimport commented 13 years ago

Robert Muir (@rmuir) (migrated from JIRA)

Hey guys, we had some hudson problems I wonder if you could look at:

The first thing, the randomization of this test was not working correctly, because it used 'random' from static initializers. In LuceneTestCase, the random is first initialized in @beforeClass, so its not really usable before then.

I committed this to fix the randomization: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/contrib/queryparser/src/test/org/apache/lucene/queryParser/standard/TestNumericQueryParser.java?r1=1145452&r2=1145451&pathrev=1145452

Once I did this, then the test is working correctly (reproducible etc) but it would fail and sometimes hang.

I took care of the hang, the reason was if the test got minIntegerDigits <4, it would loop forever looking for a number >= 1000. You can see the fix here: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/contrib/queryparser/src/test/org/apache/lucene/queryParser/standard/TestNumericQueryParser.java?view=diff&r1=1145456&r2=1145457&pathrev=1145457

But one problem still remains, for some situations (e.g. certain numbers and locales) the test is failing.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Robert,

Thanks for fixing the problems.

About the tests failing, do you know how I can reproduce it? When I was testing, whenever I hit a failure, ant would give me some seed values so I could set in the properties when re-running the tests. Do you have the same values?

asfimport commented 13 years ago

Robert Muir (@rmuir) (migrated from JIRA)

Here are some, from hudson: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9527/testReport/junit/org.apache.lucene.queryParser.standard/TestNumericQueryParser/testSimpleNumericQuery/

ant test -Dtestcase=TestNumericQueryParser -Dtestmethod=testSimpleNumericQuery -Dtests.seed=941414100019268099:-3819525649270784880 -Dtests.multiplier=3

There is no guarantee this will work though, because when randomizing locales, the number available can vary from JRE to JRE, even changing in minor versions.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I assume the problem lies in Thai locale - as always :-)

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Robert,

I updated my code to latest revision and I don't get any junit failure, I ran

ant test -Dtestcase=TestNumericQueryParser -Dtestmethod=testSimpleNumericQuery -Dtests.seed=941414100019268099:-3819525649270784880 -Dtests.multiplier=3

in contrib/queryparser and junit on eclipse with

-Dtestcase=TestNumericQueryParser -Dtestmethod=testSimpleNumericQuery -Dtests.seed=941414100019268099:-3819525649270784880 -Dtests.multiplier=3

None of them failed.

asfimport commented 13 years ago

Robert Muir (@rmuir) (migrated from JIRA)

yeah the seed will unfortunately rely upon how many locales you have on your JRE

So to get some seeds that work on your machine, can you try this script?

#!/bin/bash
x=0
while [ $x -lt 50 ]
do
  echo "test iteration number $x"
  (cd lucene/contrib/queryparser && ant test -Dtestcase=TestNumericQueryParser) >> /home/rmuir/log.txt 2>&1
  x=$(( $x + 1 ))
done
asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Robert,

Thanks for the script, it helped me to find a case where it fails.

On my JRE, the code below fails:

  SimpleDateFormat df = (SimpleDateFormat) DateFormat.getDateTimeInstance(
      DateFormat.FULL, DateFormat.LONG, new Locale("de_CH"));
  // most of date pattern do not include era, so we add it here. Also,
  // sometimes second is not available, we make sure it's present too
  df.applyPattern(df.toPattern() + " G s Z yyyy");
  df.setTimeZone(TimeZone.getTimeZone("America/Grand_Turk"));
  long l1 = -1881411016000l;
  long l2 = -1881411028000l;
  String d1 = df.format(new Date(l1));
  String d2 = df.format(new Date(l2));
  long newL1 = df.parse(d1).getTime();
  long newL2 = df.parse(d2).getTime();

  System.out.println(l1 + " => " + d1 + " => " + newL1);
  System.out.println(l2 + " => " + d2 + " => " + newL2);
  assertEquals(l1, newL1);
  assertEquals(l2, newL2);

and it outputs: 

-1881411016000 => Friday, May 20, 1910 4:42:32 AM EST => -1881411448000
-1881411028000 => Friday, May 20, 1910 4:42:20 AM EST => -1881411460000

As you can see, it seems DateFormat is not very reliable and do not convert back and forth from date(long) to string format and vice-versa.

I am planning to add a sanity check when creating randomly the date format, the check will check whether the date can be converted to/from long from/to string without data loss.

What do you think?

asfimport commented 13 years ago

Chris Male (migrated from JIRA)

Another trunk failure: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/9532/

asfimport commented 13 years ago

Chris Male (migrated from JIRA)

Also, note in #4358 I'm about to move the flexible QP over to the new queryparser module and remove the contrib.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

As you can see, it seems DateFormat is not very reliable and do not convert back and forth from date(long) to string format and vice-versa.

I would write the test a little bit different: Use a random number as basis for the date, then convert to string and back. Throw away the orginal random number and use the "normalized" number and their string representation only?

This should work better, as I assume SimpleDateFormat always produces same results for same numbers? But you can still add the sanity check and throw away random numbers that don't meet the requirement.

Additionally, the millisecond part should always be 000, as you dont use miliseconds?

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I disabled the test case for now: Trunk revision: 1145885

I would write the test a little bit different: Use a random number as basis for the date, then convert to string and back. Throw away the orginal random number and use the "normalized" number and their string representation only?

Ah, you already did that, so the DateFormats are not really reliabe, you are right!

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

This is the fix for the junit failure. I used the Robert's script and the test has not failed anymore.

asfimport commented 13 years ago

Chris Male (migrated from JIRA)

Note, I've just moved this contrib to the queryparser module and nuked the contrib. Sorry Vinicius :/

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

Hey Chris,you just moved the files right?![ Vinicus patch only includes a single file (the failing junit), all Uwe need to do is to apply the patch to the moved file, is that correct?]( Vinicus patch only includes a single file (the failing junit), all Uwe need to do is to apply the patch to the moved file, is that correct?)

asfimport commented 13 years ago

Chris Male (migrated from JIRA)

Correct.

The Flexible QueryParser can now be found at org.apache.lucene.queryparser.flexible.*

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

This is the fix for the junit failure. I used the Robert's script and the test has not failed anymore.

Thanks Vinicius, I will check the patch and apply it to the new location of the query parser. You don't need to do anything!

If you have other changes or fixes in your checkout, I would recommend to create a patch first (below the queryparser folder) and then update svn and reapply the patch at the new location.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Hi Vinicius,

I tested your patch (after converting it to new trunk directory/package layout (thanks Chris Male :-)

It still fails quite often for some locales (at least in Java 6). The problem is that some locales produce date formats that are not immune to case changes. As QueryParser seems to lowercase the range bounds, some dates cannot be parsed.

This throwed with your patch a NPE, because you implemented NumberDateFormat wrong: public Number parse(String source, ParsePosition parsePosition) is allowed to return null (it must if a parse error occurs). The same applies to date formats, but if you call getTime() on a null Date it throws NPE. So the attached patch also fixes the NumberDateFormat to handle null correctly.

I also changed the test initialization a bit to produce sane dates from the beginning.

I then added a toLowerCase(LOCALE) to the sanity checker

Now the static initializer fails for:

ant test -Dtestcase=TestNumericQueryParser -Dtestmethod=testInclusiveNumericRange -Dtests.seed=5825000776503943381:-1057095952794658416

As a lowercased date cannot be parsed, this fails with ParseException. The locale is "es", so the spanisch translation of "GMT" is case sensitive:

This parses:

domingo 19 de agosto de 1973 11H31' GAMT AD 34 -0900 1973

This not:

domingo 19 de agosto de 1973 11h31' gamt ad 34 -0900 1973
asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I would suggest to not lowercase range bounds for numbers/dates in the QueryParser. This makes only sense for terms, but numbers should not change case. I think we can remove the toLowerCase() in the query builder.

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

I agree with Uwe. I think the format passed to NumericConfig should decide if it supports or not case.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Attached you find the same patch, but with the numeric nodes not lowercased. The fix was easy: As the NumericQueryNodeProcessor transforms all text nodes to numeric nodes, we can simply move the LowerCaseExpandedTerms processor after those transformations, so the nodes are no longer touched.

The attached patch simply moves the LowercaseExpandedTermsQueryNodeProcessorfilter after the NumericRangeQueryNodeProcessor.

Tests now pass, Vinicius & Adriano, what do you think?

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Hi Uwe,

Thanks for fixing the junit, I think changing the order of those processors is OK, mainly if Numeric processors do no require lowercasing.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

I will commit those fixes ASAP to get it again into the nightly test runs (where this test is currently disabled). I never trust the complexity of all Locales, maybe there are more glitches which can only be found with random testing.

asfimport commented 13 years ago

Adriano Crestani (migrated from JIRA)

It sounds ok for me to change when LowercaseExpandedTermsQueryNodeProcessor gets executed.

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Here the patch I'll commit now. I changed the initialization order of beforeClass() a little bit to make it easier to undertstand. The NumberFormat is no longer initialized inside the Date loop, as its not used there.

I'll commit now.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

This patch includes javadocs for the changes I did so far.

I am working right now on fixing open range bug on flexible standard query parser.

asfimport commented 13 years ago

Vinicius Barros (migrated from JIRA)

Fixed open range and mixed include and exclude bugs on #4411

asfimport commented 13 years ago

Uwe Schindler (@uschindler) (migrated from JIRA)

Committed the javadocs changes in rev 1150671.