But the scenario you discribed would be no different from below:
1) txn start
2) select * where color = 'green'
3) change 1st car color to red
4) select * where color = 'green'
Obviously current containers can readily handle synchronization of entity
cache within a txn. Adding a ORDERS CLAUSE should not provide any further
burdens.
Gene
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Johan Eltes
Sent: Tuesday, May 01, 2001 11:02 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB 2.0: EJB QL no ORDER BY clause
Assume that the container keeps finder results in synch with the entity
cache during a transaction:
1) Transaction starts
2) Invoke finder on Car home, to get all green Cars
3) Get the first Car of the enumeration, and change its color to red
4) Invoke a finder on Car Home with "order by" on Color
Maybe this would add a lot of complexity to the container - it must
implement the collating strategy used by each of the databases it supports.
/Johan
-----Original Message-----
From: A mailing list for Enterprise JavaBeans development
[mailto:[EMAIL PROTECTED]]On Behalf Of Jay Walters
Sent: den 1 maj 2001 22:18
To: [EMAIL PROTECTED]
Subject: Re: EJB 2.0: EJB QL no ORDER BY clause
I agree with RMH, it's a lot easier to say "order by username" in the EJB QL
then to put a bunch of Java code in to order the collection after the fact,
and as he said it requires the container to realize the entire set of
matching objects for a finder. We often return the first 10 or 20 items out
of 100's or 1000's to the user, if we cannot sort in the database then the
whole set will need to be read into the container and sorted before sending
results to the client.
Cheers
Jay
-----Original Message-----
From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, May 01, 2001 3:53 PM
To: [EMAIL PROTECTED]
Subject: Re: EJB 2.0: EJB QL no ORDER BY clause
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".
===========================================================================
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".
