Hi, Michael, Tom,
I ran entity-persistence-tests on the change I made for InNode. The
JUnitEJBQLDateTimeTestSuite.testTimestampIn() failed because the
validation in InNode.java only allows string, numeric and enum type
according to the spec. Is the test for timestamp using IN still valid?
Should the test be removed?
Thanks.
Jielin
Michael Bouschen wrote:
> Hi Jielin,
>
> the changes look good. Two remarks:
>
> - I propose to add a method isString type to the TypeHelper interface
> and call this in InNode.validate.
> This should go into TypeHelper.java:
> /** Returns true if the specified type represents java.lang.String. */
> public boolean isStringType(Object type);
> and this should be added to BasicTypeHelper.java:
> /** Returns true if the specified type represents java.lang.String. */
> public boolean isStringType(Object type) {
> return type == getStringType();
> }
>
> - Are you planning to add a test to JUnitEJBQLValidationTestSuite in
> entity-persistence-tests? I propose to add two test cases: one where
> the in clause consists of a list of value and another using a subquery.
>
> Just a heads-up: I'm also planning to change EJBQLException, so we
> need to check for conflicts (e.g. using the same number for the
> constant etc.).
>
> Regards Michael
>
>> Hi, Michael, Tom,
>>
>> Attached is the fix for issue 136 - JPQL validation: Parser not
>> catching invalid expression type with IN expression.
>>
>> According to spec,
>> in_expression ::= state_field_path_expression [NOT] IN (in_item {,
>> in_item}* | subquery)
>> The state_field_path_expression must have a string, numeric or enum
>> value.
>> The in_item and the result of subquery must be like the same abstrct
>> schema type of the state_field_path_expression.
>>
>> Added two validation checks in InNode.java.
>>
>> Please review the change.
>>
>> Thanks.
>>
>> Jielin
>>
>>