You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by dn...@apache.org on 2004/11/24 00:14:31 UTC
cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser TestQueryParser.java
dnaber 2004/11/23 15:14:31
Modified: src/test/org/apache/lucene/queryParser TestQueryParser.java
Log:
adapt to new typesafe API
Revision Changes Path
1.33 +10 -2 jakarta-lucene/src/test/org/apache/lucene/queryParser/TestQueryParser.java
Index: TestQueryParser.java
===================================================================
RCS file: /home/cvs/jakarta-lucene/src/test/org/apache/lucene/queryParser/TestQueryParser.java,v
retrieving revision 1.32
retrieving revision 1.33
diff -u -r1.32 -r1.33
--- TestQueryParser.java 6 Oct 2004 16:19:52 -0000 1.32
+++ TestQueryParser.java 23 Nov 2004 23:14:31 -0000 1.33
@@ -108,7 +108,7 @@
if (a == null)
a = new SimpleAnalyzer();
QueryParser qp = new QueryParser("field", a);
- qp.setOperator(QueryParser.DEFAULT_OPERATOR_OR);
+ qp.setDefaultOperator(QueryParser.OR_OPERATOR);
return qp;
}
@@ -143,7 +143,7 @@
if (a == null)
a = new SimpleAnalyzer();
QueryParser qp = new QueryParser("field", a);
- qp.setOperator(QueryParser.DEFAULT_OPERATOR_AND);
+ qp.setDefaultOperator(QueryParser.AND_OPERATOR);
return qp.parse(query);
}
@@ -203,6 +203,14 @@
"+(apple \"steve jobs\") -(foo bar baz)");
assertQueryEquals("+title:(dog OR cat) -author:\"bob dole\"", null,
"+(title:dog title:cat) -author:\"bob dole\"");
+
+ QueryParser qp = new QueryParser("field", new StandardAnalyzer());
+ // make sure OR is the default:
+ assertEquals(QueryParser.OR_OPERATOR, qp.getDefaultOperator());
+ qp.setDefaultOperator(QueryParser.AND_OPERATOR);
+ assertEquals(QueryParser.AND_OPERATOR, qp.getDefaultOperator());
+ qp.setDefaultOperator(QueryParser.OR_OPERATOR);
+ assertEquals(QueryParser.OR_OPERATOR, qp.getDefaultOperator());
}
public void testPunct() throws Exception {
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser
TestQueryParser.java
Posted by Bernhard Messer <bm...@apache.org>.
Bernhard Messer schrieb:
>
>>>> Or maybe we could put together an all-encompassing
>>>> TestDeprecatedMethods that at least had calls to all the methods
>>>> we've deprecated, but doesn't necessarily test return values or
>>>> behavior. Then we could fix all the deprecation warnings in the
>>>> other test cases and leave this as the one test that at least the
>>>> method signatures are viable (and we can be reasonably sure that if
>>>> the method signatures still work that the behavior has not changed,
>>>> I presume).
>>>>
>>> creating an all-encompassing TestDeprecatedMethods class seems to be
>>> more difficult than it looks for the moment. Wouldn't it be easier
>>> to copy the Testcases from 1.4.2 in a seperate, new folder
>>> "test-deprecated" and leave them as they are. All work, removing
>>> deprecation warnings, add new test cases could be done without
>>> modifying the originals within the new folder. When we run the
>>> ant-task on both directories, we can make sure that both, the
>>> deprecated and new methods are working properly.
>>
>>
>>
>> +1
>> seems to do what we want with minimal effort
>>
> I tried it on my local environement and it looks fine to me. It's not
> that much work to create a copy of the test cases from 1.4.2. Adding a
> new ant task "test-deprecated" which uses the test classes located in
> "src/test-deprecated" is a is trivial too. At least it is just a copy
> of the existing "test" task with modified directory names. Having all
> together, users can run both tests "ant test" or "ant
> test-deprecated". The only question still open, if we want to have all
> the duplicated test cases in CVS or do we leave it to the user if he
> wants to run the outdated, deprecated tests. My suggestion is to add
> both, the modified build.xml and the test cases to CVS and delete them
> step by step when switching to version 2.0
>
if there are no votes against it, i will add the deprecated tests as
described above and commit the modification in build.xml.
Bernhard
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser
TestQueryParser.java
Posted by Bernhard Messer <bm...@apache.org>.
>>> Or maybe we could put together an all-encompassing
>>> TestDeprecatedMethods that at least had calls to all the methods
>>> we've deprecated, but doesn't necessarily test return values or
>>> behavior. Then we could fix all the deprecation warnings in the
>>> other test cases and leave this as the one test that at least the
>>> method signatures are viable (and we can be reasonably sure that if
>>> the method signatures still work that the behavior has not changed,
>>> I presume).
>>>
>> creating an all-encompassing TestDeprecatedMethods class seems to be
>> more difficult than it looks for the moment. Wouldn't it be easier to
>> copy the Testcases from 1.4.2 in a seperate, new folder
>> "test-deprecated" and leave them as they are. All work, removing
>> deprecation warnings, add new test cases could be done without
>> modifying the originals within the new folder. When we run the
>> ant-task on both directories, we can make sure that both, the
>> deprecated and new methods are working properly.
>
>
> +1
> seems to do what we want with minimal effort
>
I tried it on my local environement and it looks fine to me. It's not
that much work to create a copy of the test cases from 1.4.2. Adding a
new ant task "test-deprecated" which uses the test classes located in
"src/test-deprecated" is a is trivial too. At least it is just a copy of
the existing "test" task with modified directory names. Having all
together, users can run both tests "ant test" or "ant test-deprecated".
The only question still open, if we want to have all the duplicated test
cases in CVS or do we leave it to the user if he wants to run the
outdated, deprecated tests. My suggestion is to add both, the modified
build.xml and the test cases to CVS and delete them step by step when
switching to version 2.0
Bernhard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser
TestQueryParser.java
Posted by Christoph Goller <go...@detego-software.de>.
Bernhard Messer schrieb:
> Erik Hatcher schrieb:
>
>> On Nov 24, 2004, at 2:23 PM, Daniel Naber wrote:
>>
>>> On Wednesday 24 November 2004 10:54, Erik Hatcher wrote:
>>>
>>>> I much prefer to see our tests and complete codebase without
>>>> deprecation warnings, however it seems to be a good idea to keep our
>>>> test cases using both the new and deprecated API's until we do the full
>>>> clean-up in 2.0.
>>>
>>>
>>>
>>> I'd agree, but I'm not sure how that is possible without just copying
>>> many
>>> testcases and replacing only the deprecated calls.
>>
>>
>>
>> Sorry, my message was not quite what I meant. I didn't mean to
>> duplicate test cases, but rather leave the test cases calling the
>> deprecated methods for the time being. If it is deemed appropriate to
>> also have a new test case to test the new methods, then even better.
>>
>> Or maybe we could put together an all-encompassing
>> TestDeprecatedMethods that at least had calls to all the methods we've
>> deprecated, but doesn't necessarily test return values or behavior.
>> Then we could fix all the deprecation warnings in the other test cases
>> and leave this as the one test that at least the method signatures are
>> viable (and we can be reasonably sure that if the method signatures
>> still work that the behavior has not changed, I presume).
>>
> creating an all-encompassing TestDeprecatedMethods class seems to be
> more difficult than it looks for the moment. Wouldn't it be easier to
> copy the Testcases from 1.4.2 in a seperate, new folder
> "test-deprecated" and leave them as they are. All work, removing
> deprecation warnings, add new test cases could be done without modifying
> the originals within the new folder. When we run the ant-task on both
> directories, we can make sure that both, the deprecated and new methods
> are working properly.
+1
seems to do what we want with minimal effort
Christoph
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser
TestQueryParser.java
Posted by Bernhard Messer <bm...@apache.org>.
Erik Hatcher schrieb:
> On Nov 24, 2004, at 2:23 PM, Daniel Naber wrote:
>
>> On Wednesday 24 November 2004 10:54, Erik Hatcher wrote:
>>
>>> I much prefer to see our tests and complete codebase without
>>> deprecation warnings, however it seems to be a good idea to keep our
>>> test cases using both the new and deprecated API's until we do the full
>>> clean-up in 2.0.
>>
>>
>> I'd agree, but I'm not sure how that is possible without just copying
>> many
>> testcases and replacing only the deprecated calls.
>
>
> Sorry, my message was not quite what I meant. I didn't mean to
> duplicate test cases, but rather leave the test cases calling the
> deprecated methods for the time being. If it is deemed appropriate to
> also have a new test case to test the new methods, then even better.
>
> Or maybe we could put together an all-encompassing
> TestDeprecatedMethods that at least had calls to all the methods we've
> deprecated, but doesn't necessarily test return values or behavior.
> Then we could fix all the deprecation warnings in the other test cases
> and leave this as the one test that at least the method signatures are
> viable (and we can be reasonably sure that if the method signatures
> still work that the behavior has not changed, I presume).
>
creating an all-encompassing TestDeprecatedMethods class seems to be
more difficult than it looks for the moment. Wouldn't it be easier to
copy the Testcases from 1.4.2 in a seperate, new folder
"test-deprecated" and leave them as they are. All work, removing
deprecation warnings, add new test cases could be done without modifying
the originals within the new folder. When we run the ant-task on both
directories, we can make sure that both, the deprecated and new methods
are working properly.
Bernhard
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser TestQueryParser.java
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Nov 24, 2004, at 2:23 PM, Daniel Naber wrote:
> On Wednesday 24 November 2004 10:54, Erik Hatcher wrote:
>
>> I much prefer to see our tests and complete codebase without
>> deprecation warnings, however it seems to be a good idea to keep our
>> test cases using both the new and deprecated API's until we do the
>> full
>> clean-up in 2.0.
>
> I'd agree, but I'm not sure how that is possible without just copying
> many
> testcases and replacing only the deprecated calls.
Sorry, my message was not quite what I meant. I didn't mean to
duplicate test cases, but rather leave the test cases calling the
deprecated methods for the time being. If it is deemed appropriate to
also have a new test case to test the new methods, then even better.
Or maybe we could put together an all-encompassing
TestDeprecatedMethods that at least had calls to all the methods we've
deprecated, but doesn't necessarily test return values or behavior.
Then we could fix all the deprecation warnings in the other test cases
and leave this as the one test that at least the method signatures are
viable (and we can be reasonably sure that if the method signatures
still work that the behavior has not changed, I presume).
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser TestQueryParser.java
Posted by Daniel Naber <da...@t-online.de>.
On Wednesday 24 November 2004 10:54, Erik Hatcher wrote:
> I much prefer to see our tests and complete codebase without
> deprecation warnings, however it seems to be a good idea to keep our
> test cases using both the new and deprecated API's until we do the full
> clean-up in 2.0.
I'd agree, but I'm not sure how that is possible without just copying many
testcases and replacing only the deprecated calls.
Regards
Daniel
--
http://www.danielnaber.de
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org
Re: cvs commit: jakarta-lucene/src/test/org/apache/lucene/queryParser TestQueryParser.java
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Nov 23, 2004, at 6:14 PM, dnaber@apache.org wrote:
> dnaber 2004/11/23 15:14:31
>
> Modified: src/test/org/apache/lucene/queryParser
> TestQueryParser.java
> Log:
> adapt to new typesafe API
>
> - qp.setOperator(QueryParser.DEFAULT_OPERATOR_OR);
> + qp.setDefaultOperator(QueryParser.OR_OPERATOR);
I much prefer to see our tests and complete codebase without
deprecation warnings, however it seems to be a good idea to keep our
test cases using both the new and deprecated API's until we do the full
clean-up in 2.0. Having test cases calling deprecated methods allows
us to catch when we screw-up and actually remove a deprecated method.
This happened with QueryParser and the new getter methods recently.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: lucene-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: lucene-dev-help@jakarta.apache.org