You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by Kevin Sutter <kw...@gmail.com> on 2012/02/24 21:02:47 UTC
Removal of unnecessary "Order By" clauses
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
Re: Removal of unnecessary "Order By" clauses
Posted by Pawel Veselov <pa...@gmail.com>.
On Wed, Feb 29, 2012 at 12:06 PM, Pinaki Poddar <pp...@apache.org> wrote:
> > Extra performance cost that comes as a price for just wanting to use List
> API.
> That is not a sound argument.
>
I would compare this to coming into a store, and selecting between alarm
clocks. There is a $9.99 clock that displays time and beeps for alarm, and
there $49.99 clock that does the same plus auto-adjusts the time, has
FM/AM/CD/Sattelite receivers, and makes you coffee. The thing is that I
only wan the auto-adjust feature, and nothing else, but I'm placed in a
position that if I do want it, I have to get a fully loaded one, and pay
the maximum price.
Firstly, a performance cost is not a bug.
> Secondly, a feature i.e. to have List maintain order, it is natural that a
> provider will need some code and code costs. But that cost can not be
> termed
> as a performance cost. That is a feature cost.
>
There is a cost to maintain order across a single context, and a [much?]
higher cost to maintain order across contexts. Users are forced to pay
higher cost, even if all they want is a simpler feature. This is
effectively paying for stuff you don't need because of the stuff you do
need. And the spec seems to agree, saying that you if all you did is
requested the simpler feature (declared your collection as a List), you are
are not entitled to get a more advanced behavior (maintaining order across
contexts), and if you do, you have to explicitly request for that.
>
> With current capabilities of OpenJPA, a user determines and has complete
> control on whether s/he wants Set or List to represent a domain model
> properties. If a user does use List API it means s/he requires ordering
> semantics. And that declaration is sufficient for OpenJPA to maintain
> element ordering for him/her. So what is the confusion about "just wanting
> to use List API"?
>
>
I [might] want to use List API to make calls like get(int), and use list
iterators that allow me to traverse the list both ways. I do care that the
order of elements doesn't change between me creating iterators of a the
same list, or accessing items in the same list (so get(i) always returns
the same object). It doesn't mean that I want and/or care for the framework
to guarantee all that across persistent contexts. If I did, I would specify
@Order? annotation.
Re: Removal of unnecessary "Order By" clauses
Posted by Pinaki Poddar <pp...@apache.org>.
> Extra performance cost that comes as a price for just wanting to use List
API.
That is not a sound argument.
Firstly, a performance cost is not a bug.
Secondly, a feature i.e. to have List maintain order, it is natural that a
provider will need some code and code costs. But that cost can not be termed
as a performance cost. That is a feature cost.
With current capabilities of OpenJPA, a user determines and has complete
control on whether s/he wants Set or List to represent a domain model
properties. If a user does use List API it means s/he requires ordering
semantics. And that declaration is sufficient for OpenJPA to maintain
element ordering for him/her. So what is the confusion about "just wanting
to use List API"?
-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/Removal-of-unnecessary-Order-By-clauses-tp7315925p7330537.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Removal of unnecessary "Order By" clauses
Posted by Pawel Veselov <pa...@gmail.com>.
On 02/29/2012 11:30 AM, Pinaki Poddar wrote:
>> that this just sounds like a bug...
> "OpenJPA allows a java.util.List type field to maintain order without any
> further annotation across persistence context" -- and that is a bug!
>
> Spec says that list ordering is not portable -- spec does not prohibit a
> vendor to provide features. So what is the bug here?
Extra performance cost that comes as a price for just wanting to use
List API.
Re: Removal of unnecessary "Order By" clauses
Posted by Pinaki Poddar <pp...@apache.org>.
> that this just sounds like a bug...
"OpenJPA allows a java.util.List type field to maintain order without any
further annotation across persistence context" -- and that is a bug!
Spec says that list ordering is not portable -- spec does not prohibit a
vendor to provide features. So what is the bug here?
-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/Removal-of-unnecessary-Order-By-clauses-tp7315925p7330422.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Removal of unnecessary "Order By" clauses
Posted by Kevin Sutter <kw...@gmail.com>.
I agree with Pawel. If we leave the Order By clause present for all List
types, then there is no way out. But, if we remove the Order By clause for
the List types (per the spec), then users have the option to designate an
ordering via the OrderColumn or OrderBy annotations. I'm beginning to lean
towards Pawel's earlier remark that this just sounds like a bug...
Kevin
On Wed, Feb 29, 2012 at 12:49 PM, Pawel Veselov <pa...@gmail.com>wrote:
> Well, but the spec explicitly says that you shouldn't count on the order to
> be same across contexts. There is a cost to do an 'order by' clause, and if
> all what I want is to arrange my objects in a list (because I want to use
> list API calls), I have to pay the cost, and there is no option for me.
>
> On Wed, Feb 29, 2012 at 10:14 AM, Pinaki Poddar <pp...@apache.org>
> wrote:
>
> > A persistent property declared as a list maintains its order across
> > persistence contexts is a useful feature. It does not sound unnecessary
> to
> > me as an user. If the user does not require the order, the field can be
> > declared as Collection or Set. Why to take away an useful feature?
> >
> >
>
Re: Removal of unnecessary "Order By" clauses
Posted by Pawel Veselov <pa...@gmail.com>.
Well, but the spec explicitly says that you shouldn't count on the order to
be same across contexts. There is a cost to do an 'order by' clause, and if
all what I want is to arrange my objects in a list (because I want to use
list API calls), I have to pay the cost, and there is no option for me.
On Wed, Feb 29, 2012 at 10:14 AM, Pinaki Poddar <pp...@apache.org> wrote:
> A persistent property declared as a list maintains its order across
> persistence contexts is a useful feature. It does not sound unnecessary to
> me as an user. If the user does not require the order, the field can be
> declared as Collection or Set. Why to take away an useful feature?
>
>
Re: Removal of unnecessary "Order By" clauses
Posted by Pinaki Poddar <pp...@apache.org>.
A persistent property declared as a list maintains its order across
persistence contexts is a useful feature. It does not sound unnecessary to
me as an user. If the user does not require the order, the field can be
declared as Collection or Set. Why to take away an useful feature?
-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/Removal-of-unnecessary-Order-By-clauses-tp7315925p7330183.html
Sent from the OpenJPA Users mailing list archive at Nabble.com.
Re: Removal of unnecessary "Order By" clauses
Posted by Pawel Veselov <pa...@gmail.com>.
Hi.
From what you are describing here, with the spec references, the
current behavior looks like a bug (may be a performance bug only, but
still).
Thanks,
Pawel.
On 02/24/2012 12:02 PM, Kevin Sutter wrote:
> 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
>