ejbFind and ejbSelect return types

[Constantino Cronemberger]

Is it true that for CMP Entity Beans, all select methods, and all finder methods but findByPrimaryKey must return a collection (or set)?
I made this supposition based on the fact that for CMP the container is responsible for generating those methods base on the EJB-QL for each method, and in the EJB-QL language there is no way to force the result to be just one value or row.
If it is not true, I have another question: How does the container decide which value to return from the result set? Does it take the first element? Or does it raise an exception when the result set has more then one element?

[Reid M. Pinchback]

ejbSelect and ejbFind have three options:
1. return a single object reference
2. return java.util.Collection
3. return java.util.Set
No other option is allowed. I didn't see anything in the spec that said what would happen if you want a single object reference but you wrote a query that would sometimes finds multiple items. Since the queries will typically get mapped into JDBC calls, you'd expect to get whatever the database happened to choose as the first row of the ResultSet; anything else would be pointlessly inefficient (because the container wouldn't know which row you wanted, so any choice of row is as good as any other - the container may as well be wrong and fast instead of wrong and slow).
Sun reasonably could argue that it isn't the EJB spec's job to overly describe what happens when the bean isn't implemented correctly, any more than the Java language spec spends effort on describing the consequences of coding bugs. Getting the EJB-QL correct so that it finds only one item when you only expect one item is necessarily part of the bean provider's (as the EJB-QL writer) and deployer's (in setting up the database) jobs. Bugs probably aren't intended to be overly portable. :-)

[cyril vidal]

Reid wrote:

ejbSelect and ejbFind have three options:
1. return a single object reference
2. return java.util.Collection
3. return java.util.Set

It's not exactly true.
You may also return a CMP field with the ejbSelect() method.
And about the original question about the return type, the only worth question is not about the number of results but about the type (local or remote) of the returned object.
This only concerns the ejbSelect() method that is defined in the bean class and not in the (local or remote) home interface. So you have to specify it in DD with the <result-type-mapping> element.
Regards,
Cyril.
[ March 09, 2004: Message edited by: cyril vidal ]

[Reid M. Pinchback]

Oops, you are correct, I forgot about the CMP fields.

[David O'Brien]

Reid
as I understand it the spec says the container must
throw a FinderException if a single object finder
returns multiple objects (10.5.6.1) or if a single
object select return multiple objects (10.5.7.1)

[Vishwa Kumba]

Originally posted by David O'Brien:
As I understand it the spec says the container must
throw a FinderException if a single object finder
returns multiple objects (10.5.6.1) or if a single
object select return multiple objects (10.5.7.1)

Thanks David!
for pointing it out in the spec. For the benefit of the others, I have enclosed the bean law from the specs...
P:182, Sec 10.5.6.1

If the query specified by the finder method returns multiple values of the designated entity object type, the container must throw the FinderException from the finder method.

P:183, Sec 10.5.7.1

Some select methods are designed to return at most one value. In general, when defining a single-object select method, the entity Bean Provider must be sure that the select method will always return only a
single object or value. If the query specified by the select method returns multiple values of the designated type, the Container must throw the
FinderException.
The Bean Provider will typically define a select method as a multi-object select method.