Negative [VOTE]: Issue 146: TCK : ResultClassRequirements.testNegative

[Craig L Russell <Cr...@Sun.COM>]

Javadogs,

Please reply if you do not agree with this change.

Craig

I've reviewed the spec and I'm inclined to agree with Andy about the  
intent, and with both Andy and Michael about the exact wording of the  
specification, which does appear to disallow the negative test case  
as written. Although there is some ambiguity that I think we should  
clean up regardless.

It seems that the following queries have the same semantics but due  
to the way the spec is written, have very different behavior. The  
first query disallows the use of the (long, String) constructor  
whereas the second query could use set or put methods if there were  
no corresponding constructor (even though a constructor appears to be  
called for by the use of the "new" keyword). As an aside, the first  
query seems to be more readable...

SELECT personid, lastname
INTO org.apache.jdo.tck.query.result.classes.LongString
FROM org.apache.jdo.tck.pc.company.FullTimeEmployee

SELECT new org.apache.jdo.tck.query.result.classes.LongString  
(personid, lastname)
FROM org.apache.jdo.tck.pc.company.FullTimeEmployee

I remember having the discussion about constructors when we talked  
about the constructor specification in the setResult versus the  
constructor in the setResultClass. I do not remember why we chose to  
restrict the case discussed in the bug report. It could simply be my  
bad transcription of the discussion.

To remedy this, I propose changing the spec to move the  
setResultClass phrase. This change implements Andy's suggestion  
below, making the above queries semantically and behaviorally  
equivalent.

<spec 14.6.12>
A constructor of a result class specified in the setResult method  
will be used if the results specification matches the parameters of  
the constructor by position and type. If more than one constructor  
satisfies the requirements, the JDO implementation chooses one of  
them. If no constructor satisfies the results requirements, or if the  
result class is specified via the setResultClass method, the  
following requirements apply:
</spec 14.6.12>

<proposed 14.6.12>
A constructor of a result class specified in the constructor  
expression of the setResult method or in the setResultClass method  
will be used if the results specification matches the parameters of  
the constructor by position and type. If more than one constructor  
satisfies the requirements, the JDO implementation chooses one of  
them. If no constructor satisfies the results requirements, the  
following requirements apply:
</proposed 14.6.12>

On Nov 23, 2005, at 10:45 AM, Andy Jefferson wrote:

> Hi Michael,
>
>>> SELECT personid, lastname INTO
>>> org.apache.jdo.tck.query.result.classes.LongString FROM
>>> org.apache.jdo.tck.pc.company.FullTimeEmployee
>>>
>>> Now referring to 14.6.12, the impl needs to find a constructor  
>>> taking the
>>> expressions by position and type. It finds a constructor
>>> LongString(long,String) and so can use it to create a result  
>>> object. Why is
>>> this supposed to throw an exception exactly ?
>
>> The query has an INTO clause specifying a result class. For this
>> reason, the constructor LongString(long, String) should not be  
>> chosen.
>
> OK, your test is following the "rules" in the latest spec to the  
> letter :-).
> I prefer to look at it from a user viewpoint. "setResultClass" is  
> the place
> where the vast majority of people will specify the result class.  
> The spec
> seemingly isn't allowing a user to provide a result class with the  
> correct
> constructor parameters and use that to construct the object. This is a
> limitation that I see no obvious reason for. Is there a reason ?
>
> IMHO, the sequence should be
> 1. Use a constructor with the parameter positions/types.
>
> or
>
> 2. Use a default constructor
> 2a. public fields matching name and type
> 2b. public set method matching name and type
> 2c. public put(Object, Object) method
>
>
> -- 
> Andy

Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!


Craig Russell
Architect, Sun Java Enterprise System http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell@sun.com
P.S. A good JDO? O, Gasp!