You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jdo-dev@db.apache.org by Andy Jefferson <an...@jpox.org> on 2005/11/23 17:30:34 UTC
TCK : ResultClassRequirements.testNegative
Quick question about the INVALID_QUERIES. The first one has
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 ? OK, the expressions don't have
the same names as the fields in the result class, but is that important ?
--
Andy
Re: Issue 146: TCK : ResultClassRequirements.testNegative
Posted by Michael Bouschen <mb...@spree.de>.
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
Negative [VOTE]: Issue 146: TCK : ResultClassRequirements.testNegative
Posted by 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!
Issue 146: TCK : ResultClassRequirements.testNegative
Posted by Craig L Russell <Cr...@Sun.COM>.
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!
Re: TCK : ResultClassRequirements.testNegative
Posted by Andy Jefferson <an...@jpox.org>.
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
Re: TCK : ResultClassRequirements.testNegative
Posted by Michael Watzek <mw...@spree.de>.
Hi Andy,
the forth bullet of the assertion 14.6.12 says that if a result class is
specified, then the algorithm applies which looks for public fields,
public set methods, and put method.
The query below has an INTO clause specifying a result class. For this
reason, the constructor LongString(long, String) should not be chosen.
Regards,
Michael
> Quick question about the INVALID_QUERIES. The first one has
>
> 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 ? OK, the expressions don't have
> the same names as the fields in the result class, but is that important ?
>
--
-------------------------------------------------------------------
Michael Watzek Tech@Spree Engineering GmbH
mailto:mwa.tech@spree.de Buelowstr. 66
Tel.: ++49/30/235 520 36 10783 Berlin - Germany
Fax.: ++49/30/217 520 12 http://www.spree.de/
-------------------------------------------------------------------