As we have noted in the spec, we hope to extend EJB in the future to
include List as a cmr-field type and EJB QL result type.
The issues involved, however, are not as simple as they might appear
at first glance. Before adding this feature we will want to gather
further input from our expert group and members of the community who
are experts in the area of database and object-relational mapping
technologies.
One of our goals for EJB QL has been that it should be optimizable--
particularly by allowing queries to be pushed to the database, rather
than requiring them to be executed in memory.
The issue of ORDER BY raises some interesting issues in this regard:
Is the semantics of ordering defined by the database semantics (e.g.
SQL semantics) or by Java semantics? While maintaining Java semantics
would seem desirable, it means that we cannot generally push the
ordering down into the database, because these semantics may differ,
most notably in the case of strings, where the semantics of comparison
are further dependent on the particular representation chosen for
strings in the persistent store.
If the ordering can't be pushed into the database, then strategies for
the loading of the EJB class instances is impacted. That is, whereas
currently the query processor can return primary keys representing the
EJBObjects that need to be returned to the client, if ordering is
imposed then the query processor needs to return sufficient instance
data to allow the ordering predicate to be executed in memory, and
materialization of the instances can no longer be done lazily. While
bulk loading of the instance data may sometimes be desirable, it is
not always desirable.
With regard to List representations for cmr-fields, we will also have
to address the issue as to what it means to maintain the list as a
list (e.g., is it ordered by some predicate which the container is
expected to maintain?). This affects the container's responsibilities
with regard to referential integrity maintenance when the relationship
is updated from either side and would require additional machinery to
achieve.
Anyway...just a few of the items that need to be considered, and for
which your input will be helpful when we further evolve EJB.
regards,
Linda
>X-Accept-Language: en
>MIME-Version: 1.0
>Content-Transfer-Encoding: 8bit
>Date: Thu, 17 May 2001 18:49:31 -0500
>From: Richard Monson-Haefel <[EMAIL PROTECTED]>
>Subject: Re: EJB-Spec: Why is List not a valid finder return type?
>Comments: To: Robert Krueger <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>
>I have to agree with a lot of what Robert is saying here. There doesn't seem
>to be a good reason for not supporting the ORDER BY clause in EJB QL and, by
>default, the List collection type. A while ago, I posted a proposal for adding
>the ORDER BY clause to EJB QL, but didn't get a satisfactory response from
>vendors or Sun. Why is that? What is so difficult about the ORDER BY clause
>and List collection type that they are not supported in the specification?
>
>While this issue may seem trivial, it's not. Ordered collections are
>fundamental and their absence is troubling. If there is a good explanation for
>not including the ORDER BY clause in EJB QL and, by default, the List
>collection type, I would like to hear it.
>
>Richard
>--
>Richard Monson-Haefel
>Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
>Co-Author of Java Message Service (O'Reilly 2000)
>http://www.jMiddleware.com
>
>Robert Krueger wrote:
>
>> What is the reason to not allow java.util.List as a valid return type for
>> finders? This forces us to frequently write semantically incorrect programs
>> as we rely on the order of items in the collection (because any O/R layer I
>> know allows to specify the order for CMP finders). Why not allow List as a
>> return type to get rid of this IMHO unnecessary incorrectness? Same holds
>> for collection valued CMR fields. I disagree with the assessment that
>> relying on the order of things is bad practice and agree with people
>> arguing for an ORDER BY clause in EJB-QL in the thread started by RMH. I
>> just don't see why? Looking at all EJB applications I've worked with for
>> the past 2 years, I think this is completely against common practice and I
>> don't even see a semantical problem with using ordered collections for
>> finder results (and CMR fields btw). How many persistent stores that CMP
>> engines are build on top of don't support ordering of query results? What
>> this will lead to is that container providers will probably provide
>> additional means to specify an order for finders because people need it,
>> which again will lead to non-portable apps.
>>
>> Regards,
>>
>> Robert
>>
>> (-) Robert Kr�ger
>> (-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
>> (-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
>> (-) Tel: 06151 665401, Fax: 06151 665373
>> (-) [EMAIL PROTECTED], www.signal7.de
>>
>> ===========================================================================
>> To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>> of the message "signoff EJB-INTEREST". For general help, send email to
>> [EMAIL PROTECTED] and include in the body of the message "help".
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff EJB-INTEREST". For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
