db-jdo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Bouschen <mbo.t...@spree.de>
Subject Re: Issue 146: TCK : ResultClassRequirements.testNegative
Date Wed, 23 Nov 2005 22:35:43 GMT
Hi Craig,

+1 to change the spec as proposed.

Regards Michael

> Hi,
>
> 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!
>
>


-- 
Michael Bouschen		Tech@Spree Engineering GmbH
mailto:mbo.tech@spree.de	http://www.tech.spree.de/
Tel.:++49/30/235 520-33		Buelowstr. 66			
Fax.:++49/30/2175 2012		D-10783 Berlin			


Mime
View raw message