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:[EMAIL PROTECTED]
P.S. A good JDO? O, Gasp!
