Thanks, Linda. Please see below ... (Note: I've turned the discussion back to support for the ORDER BY clause). Linda DeMichiel wrote: > 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. In light of these possible differences, it seams like you have a reasonable argument, but only for avoiding the use of List and limiting the quality of portability of ORDER BY. It's not a good argument for failing to support the ORDER BY clause. Bean developers can live with less then prefect portability of the ORDER BY clause, but they can not live without the ORDER BY clause. It seems reasonable that the exact semantics of ordering be specified as being vendor/database dependent and that the ORDER BY clause be considered less then perfectly portable. I think after EJB QL is in wide spread use we will discover other portability problems (normal for a new language) and ORDER BY will be considered the least of these problems. Perhaps the only way the EJB team can be convinced that ORDER BY is a "must have" for EJB QL is if the EJB community demands its, now before the spec is finalized. I urge EJB community to take a close look at your existing and planned applications and make a determination of the importance of the ORDER BY clause. I'm pretty confident you will discover that its not only a good idea, but you can't function without it. Please let Sun know you need the ORDER BY clause before the spec is finalized. > > 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. I would prefer that the ordering be pushed to the database, so I'm not going to address this one. > 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. This is a no brainier in my opinion. First , I was only talking about the List type as a return type for finder and select methods that use the ORDER BY clause, not as a cmr-field type. However, if semantics of the List collection type create a problem, simply use the java.util.Collection type for ordered queries. Your arguments against using the List type are well founded, and I agree with you, but its not a reason to abandon the inclusion of the ORDER BY clause. -- 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 =========================================================================== 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".
