openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Sutter <kwsut...@gmail.com>
Subject Removal of unnecessary "Order By" clauses
Date Fri, 24 Feb 2012 20:02:47 GMT
Hi,
I recently came across this issue...  OpenJPA generates SQL with an "Order
By" clause whenever the declared type is a List -- and without an
OrderColumn or OrderBy annotation.  All that is required is for the
declared type to be List (vs a Collection, Set, etc) and we insert the
"Order By" clause.

OpenJPA has been doing this for a long, long time (since day one?).  I did
find this JIRA (https://issues.apache.org/jira/browse/OPENJPA-710) where at
least we decided that it should only be done for List types.  But, that was
back in Sept 2008.  Before that, we were doing it for all collection-based
relationships...

So, my question is, what type of impact will this have on our users?  I'd
like to correct this.  From a JPA processing perspective, it's a nit.  But,
there is an associated cost with the databases and we're always concerned
about the performance of our generated SQL.

The use of this "Order By" is not a requirement of the JPA specification.
As a matter of fact, they have a footnote where it explains not to rely on
any given order unless you are using an OrderColumn or OrderBy construct.

*[3] Portable applications should not expect the order of a list to be
maintained across persistence contexts unless the OrderColumn*
*construct is used or unless the OrderBy construct is used and the
modifications to the list observe the specified ordering.*

What do you think?  Is anyone aware of a dependency where this type of
change would affect them?  Even if I make this change, I would still
provide a Compatibility switch that would allow you to get back to the old
(incorrect) behavior.  It's just that since this processing has been there
for so long, it makes me a little nervous making this type of change.

Thoughts?

Kevin

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message