WRT ORDER BY, I understand what you are saying and appreciate your point.
However, due to the volume of data in enterprise systems I think it will be
necessary to push the sorting to the database. Is it possible there could be
a way that vendors can extend the EJB QL while maintaining the base BNF
given by the spec?
Thanks,
John Harby
>From: Linda DeMichiel <[EMAIL PROTECTED]>
>Reply-To: Linda DeMichiel <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: EJB-Spec: Why is List not a valid finder return type?
>Date: Fri, 18 May 2001 15:41:19 -0700
>
>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
>
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
===========================================================================
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".
