Its seems to me that the ORDER BY clause has a couple big advantages: (1) Its
clearly communicates the bean developer's intentions; and (2) it gives the app
server vendors the option of delegating ordering to the resources.
(1)
The ORDER BY clause provides an extremely clear way for the bean developer to
communicate his intentions to the deployer and the EJB QL interpreter. The ORDER
BY clause is unambiguous; it states exactly how a collection should be ordered
(the attributes to order by, asc, desc, etc.) . After all, it's the purpose of
EJB QL to clearly commentate the behavior of the find and select operations in a
portable fashion. The omission of the ORDER BY clause prevents EJB QL from
realizing this goal.
(2)
With an ORDER BY clause, EJB QL interpreters will in many cases choose an ordering
mechanism that is optimized for a particular resource. Allowing the resource to
perform the ordering will be more efficient and performant in most cases than
having the container do it. However, even if the application server vendor
chooses to place the onus of ordering on the container's collection facilities
(see Sean Neville post), the ORDER BY clause is valuable for determining what kind
of comparisons to use. Its up to the vendor to choose how to support the ORDER
BY clause. For resources that support it, ordering could be delegated to the
resource. For those resources that don't support ordering, it can be performed by
container. (On another note forcing the container's collections to do the
ordering prevents any kind of lazy loading, since all the results must be
available for them to be ordered.)
IMO, its very simple and easy to justify: The ORDER BY clause allows the bean
developer to clearly commentate how the collection should be organized. Without
it, you have to guess or read comments, and we all know that the later doesn't
work. Second, the ORDER BY allows the app server to delegate ordering to the
resource via the EJB QL interpreter. Without an ORDER BY clause the deployer will
have to manipulate interactions of the container with the resource manually or
force the container's collection implementations to do the ordering. Given a
choice would you rather have the RDBM order your results or the app server code?
I'll put my bets on the RDBMS (if that's what I'm using) when it comes to
performance.
If all this seems like a small deal, just wait until people starting trying to use
EJB 2.0 CMP in production environments. They'll be screaming for an ORDER BY
clause. Go through your own business code and see how often ordering results is
required. Then think about what a pain it will be to always get un-ordered results
from the EJB container. How difficult it will be when you can't communicate how
you want finders or selects to order your results. Its not a small problem.
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
James Cook wrote:
> Barring something that I have overlooked, I don't think a reliance on an order
> by clause is a good practice. Ordering is something that should be done after
> the collection is realized.
>
> jim
>
> ----- Original Message -----
> From: "Jay Walters" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, May 01, 2001 12:22 PM
> Subject: Re: EJB 2.0: EJB QL no ORDER BY clause
>
> > This may seem tangential, but are Java 2 Collections considered ordered?
> > There is clearly no restriction that they can't be ordered, but somebody for
> > some reason decided to use Collection for the return type of multi-object
> > finders instead of List.
> >
> > Cheers
> > Jay
> >
> > -----Original Message-----
> > From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, April 30, 2001 1:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: EJB 2.0: EJB QL no ORDER BY clause
> >
> >
> > EJB QL is missing an ORDER BY clause. I think this is an important
> > omissions. This feature should be supported by just about every target
> > environment, so why isn't included in EJB QL?
> >
> > NOTE:
> > If you are interested in debating the virtues of EJB QL itself, kindly
> > do so in a separate thread. I'm just looking for feedback on this one
> > issue.
> >
> > Thanks,
> >
> > 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
> >
> > ===========================================================================
> > 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".
> >
> >
>
> ===========================================================================
> 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".
