Recently, I read the section above Lucene in action and ran several test cases. Because this book was written in Lucene 1.4, and I am using Version 2.2, there must be some changes to the method or class. In my opinion, constantscorerangequery is very helpful for the new class (which looks like version 1.9) added in version 1.9.
Public void testrangequery () throws parseexception {
Query = queryparser. parse ("[01/02/06 to 12/31/06]");
Asserttrue (query instanceof rangequery );
System. Out. println ("query is:/" "+ query. tostring () + "/"");
}
If you use the previous 1.4 version, the assertions will certainly not go wrong, because
A query that matches events ents within an exclusive range. A rangequery is built by queryparser for input like 010 to 120]
However, the current version is added to the constantscorerangequery class, so
The queryparser default behaviour is to use the newer constantscorerangequery class.
Therefore, the preceding test case should be changed:
Public void testrangequery () throws parseexception {
Query = queryparser. parse ("[01/02/06 to 12/31/06]");
Asserttrue (query instanceof constantscorerangequery );
System. Out. println ("query is:/" "+ query. tostring () + "/"");
}
If you want to use the previous rangequery for parsing, the new version is also backward compatible with the old rangequery:
Only if the queryparser has the useoldrangequery property set to true.
The use case should be modified as follows:
Public void testrangequery () throws parseexception {
Queryparser. setuseoldrangequery (true );
Query = queryparser. parse ("[01/02/06 to 12/31/06]");
Asserttrue (query instanceof rangequery );
System. Out. println ("query is:/" "+ query. tostring () + "/"");
}
The difference between constantscorerangequery and rangequery is:
It is faster than rangequery
Unlike rangequery, it does not cause a booleanquery. toomanyclses exception if the range of values is large
Unlike rangequery it does not influence scoring Based on the scarcity of individual terms that may match