You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@deltaspike.apache.org by Luigi Bitonti <uk...@yahoo.com.INVALID> on 2016/04/04 12:35:19 UTC
Re: OrderByQueryStringPostProcessor
Hi John,
I've created a fix for this, which you filed as DELTASPIKE-1105. Would you accept a patch (as per http://deltaspike.apache.org/community.html) or a pull request?
Cheers,Luigi
On Thursday, March 31, 2016 12:43 PM, John D. Ament <jo...@apache.org> wrote:
Hi Luigi,
I think really the only way to solve this is to add the methods to disable prefixing the entity name. Even adding more attributes to control the entity name won't fix it, as the join problem you described will exist.
John
On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <uk...@yahoo.com.invalid> wrote:
Hi John,
Many thanks for your help with this. I am afraid neither of your solutions would work for what I can see.
What I am currently trying to implement is custom (i.e. client selected) sorting for a jpaql query. Something that looks a bit like this (in a simplified version as the real thing is more complex):
SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH bi2.location l WHERE b.organisation = :organisation AND b.timeFrom < :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
If I use 'e' instead of 'b' as alias for the Booking entity, everything works if I only order by attributes of Booking (e.g. e.timeFrom), but I cannot order by e.items.id as I get an error (using eclipselink at least) that the attribute cannot be accessed as I should really be using bi2.id, which I cannot use though as that is transformed into e.b2.id.
The only solution that I can see would work with every use case I can think of, is to have a way to avoid the 'e' being prepended. This could be:
1) Adding 2 extra methods to QueryResult that allow to order by a raw string attribute (i.e. as it is). These could be called orderAscRaw and orderDescRaw or something similar.
2) Alternatively, a similar solution could be that there are overloaded versions of orderAsc(String attribute, boolean useEntityPrefix) and orderDesc. This still adds 2 extra methods to the interface (which is not really great).
3) Using a hint, but for what I can see this would be ugly in my opinion as the hint might be applied after the sorting(s) and therefore the implementation would have to "scan" the query and remove existing 'e' prefixes from the order by clause.
I am not a great fan of overloading, so I'd personally go with 1), but I am not sure if this is acceptable or there are better solutions I have overlooked. If it is acceptable I can make the change a create a pull request if that helps.
Cheers,Luigi
On Thursday, March 31, 2016 1:09 AM, John D. Ament <jo...@apache.org> wrote:
Luigi,
Actually would you be able to provide the exact query statement you have in your repo. The reason it fails in this test is because the query looks like this:
@Query("select s from Simple s") public abstract QueryResult<Simple> queryAll();
Whereas the identifier is expecting e, in order to work with QueryResult. A similar problem happens with the named query when I change the identifier.
There's a couple of thoughts I had.1. We can introduce an attribute in query (or even a hint) that says what the identifier is in "select s from Something s". This would be more robust and configurable, but introduce a burden.
2. Update documentation to clarify that "e" should be used as your query identifier by default.
John
On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org> wrote:
Thank you Luigi!I'm able to reproduce, I'll create a ticket.
John
On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com> wrote:
Hi John,
If you add the following test to QueryResultTest.java in deltaspike-data-module:
@Test public void should_sort_all_result() { List<Simple> result = repo.queryAll()
.orderDesc(Simple_.counter) .orderAsc(Simple_.id) .getResultList(); }
You'll get the following error:
Tests in error: should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest): org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path: 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s order by e.counter DESC,e.id ASC]
This is an overly simplistic case that could be worked around by using 'e' as an alias in queryAll (instead of 's'), but in more complex case with joins and order by clauses that use associated entities there's no workaround that I can see.
I tried (briefly I must confess) to work around this by creating an alternative QueryBuilderFactory that could then allow me to avoid using WrappedQueryBuilder, DefaultQueryResult and (ultimately) OrderByQueryStringPostProcessor but code duplication made the solution rather ugly, so I gave up and decided to ask.
Cheers,Luigi
On Wednesday, March 30, 2016 12:32 AM, John D. Ament <jo...@apache.org> wrote:
Luigi,
Do you happen to have a test that can reproduce this?
John
On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti <uk...@yahoo.com.invalid> wrote:
Hi all,
I am having issues with using the orderAsc and orderDesc methods on QueryResult as the order by clause always ends up having an "e." prepended to its sort-by properties (e.g "...order by e.i.date_from" instead of "...order by i.date_from". Is there any way to avoid that from happening?I am using Deltaspike 1.4.2 but from what I can see in the OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and also current git master.
Many thanks,Luigi
Re: OrderByQueryStringPostProcessor
Posted by "John D. Ament" <jo...@apache.org>.
Ah yes good point. Fixed.
On Tue, Apr 5, 2016 at 4:13 AM Luigi Bitonti <uk...@yahoo.com.invalid>
wrote:
> The note reads well, but isn't the example just before it
> (personRepository.findAllByAge...) inaccurate?
> Shouldn't that use .orderAsc("p.lastName", false) and .orderDesc("p.age",
> false)?
> Luigi
>
>
>
> On Monday, April 4, 2016 8:07 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
> I added a note to the docs about the extra method
>
> https://deltaspike.apache.org/documentation/data.html#QueryOptions21
>
> If you want to look and give feedback.
>
> John
>
> On Mon, Apr 4, 2016 at 3:02 PM Luigi Bitonti <uk...@yahoo.com.invalid>
> wrote:
>
> > Ok, fantastic. Many thanks for that.
> > Cheers,Luigi
> >
> > On Monday, April 4, 2016 5:44 PM, John D. Ament <
> johndament@apache.org>
> > wrote:
> >
> >
> > Luigi,
> >
> > I actually already pushed in a fix.
> >
> > John
> >
> > On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <uk...@yahoo.com> wrote:
> >
> > > Hi John,
> > >
> > > I've created a fix for this, which you filed as DELTASPIKE-1105. Would
> > you
> > > accept a patch (as per http://deltaspike.apache.org/community.html)
> or a
> > > pull request?
> > >
> > > Cheers,
> > > Luigi
> > >
> > >
> > >
> > > On Thursday, March 31, 2016 12:43 PM, John D. Ament <
> > johndament@apache.org>
> > > wrote:
> > >
> > >
> > > Hi Luigi,
> > >
> > > I think really the only way to solve this is to add the methods to
> > disable
> > > prefixing the entity name. Even adding more attributes to control the
> > > entity name won't fix it, as the join problem you described will exist.
> > >
> > > John
> > >
> > > On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti
> <uknadors@yahoo.com.invalid
> > >
> > > wrote:
> > >
> > > Hi John,
> > > Many thanks for your help with this. I am afraid neither of your
> > solutions
> > > would work for what I can see.
> > > What I am currently trying to implement is custom (i.e. client
> selected)
> > > sorting for a jpaql query. Something that looks a bit like this (in a
> > > simplified version as the real thing is more complex):
> > > SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH
> > > bi2.location l WHERE b.organisation = :organisation AND b.timeFrom <
> > > :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
> > > If I use 'e' instead of 'b' as alias for the Booking entity, everything
> > > works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> > > cannot order by e.items.id as I get an error (using eclipselink at
> > > least) that the attribute cannot be accessed as I should really be
> using
> > > bi2.id, which I cannot use though as that is transformed into e.b2.id.
> > > The only solution that I can see would work with every use case I can
> > > think of, is to have a way to avoid the 'e' being prepended. This could
> > be:
> > > 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> > > string attribute (i.e. as it is). These could be called orderAscRaw and
> > > orderDescRaw or something similar.
> > > 2) Alternatively, a similar solution could be that there are overloaded
> > > versions of orderAsc(String attribute, boolean useEntityPrefix) and
> > > orderDesc. This still adds 2 extra methods to the interface (which is
> not
> > > really great).
> > > 3) Using a hint, but for what I can see this would be ugly in my
> opinion
> > > as the hint might be applied after the sorting(s) and therefore the
> > > implementation would have to "scan" the query and remove existing 'e'
> > > prefixes from the order by clause.
> > > I am not a great fan of overloading, so I'd personally go with 1), but
> I
> > > am not sure if this is acceptable or there are better solutions I have
> > > overlooked. If it is acceptable I can make the change a create a pull
> > > request if that helps.
> > > Cheers,Luigi
> > >
> > > On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> > > johndament@apache.org> wrote:
> > >
> > >
> > > Luigi,
> > > Actually would you be able to provide the exact query statement you
> have
> > > in your repo. The reason it fails in this test is because the query
> > looks
> > > like this:
> > > @Query("select s from Simple s") public abstract QueryResult<Simple>
> > > queryAll();
> > > Whereas the identifier is expecting e, in order to work with
> QueryResult.
> > > A similar problem happens with the named query when I change the
> > identifier.
> > > There's a couple of thoughts I had.1. We can introduce an attribute in
> > > query (or even a hint) that says what the identifier is in "select s
> from
> > > Something s". This would be more robust and configurable, but
> introduce
> > a
> > > burden.
> > > 2. Update documentation to clarify that "e" should be used as your
> query
> > > identifier by default.
> > > John
> > > On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org>
> > > wrote:
> > >
> > > Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> > > John
> > >
> > > On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com>
> > wrote:
> > >
> > > Hi John,
> > > If you add the following test to QueryResultTest.java in
> > > deltaspike-data-module:
> > > @Test public void should_sort_all_result() {
> List<Simple>
> > > result = repo.queryAll()
> > > .orderDesc(Simple_.counter)
> > > .orderAsc(Simple_.id) .getResultList(); }
> > > You'll get the following error:
> > >
> > > Tests in error:
> > >
> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> > > org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> > > 'e.counter' [select s from
> org.apache.deltaspike.data.test.domain.Simple
> > s
> > > order by e.counter DESC,e.id ASC]
> > > This is an overly simplistic case that could be worked around by using
> > 'e'
> > > as an alias in queryAll (instead of 's'), but in more complex case with
> > > joins and order by clauses that use associated entities there's no
> > > workaround that I can see.
> > > I tried (briefly I must confess) to work around this by creating an
> > > alternative QueryBuilderFactory that could then allow me to avoid using
> > > WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> > > OrderByQueryStringPostProcessor but code duplication made the solution
> > > rather ugly, so I gave up and decided to ask.
> > > Cheers,Luigi
> > > On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> > > johndament@apache.org> wrote:
> > >
> > >
> > > Luigi,
> > > Do you happen to have a test that can reproduce this?
> > > John
> > >
> > > On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti
> <uknadors@yahoo.com.invalid
> > >
> > > wrote:
> > >
> > > Hi all,
> > > I am having issues with using the orderAsc and orderDesc methods on
> > > QueryResult as the order by clause always ends up having an "e."
> > prepended
> > > to its sort-by properties (e.g "...order by e.i.date_from" instead of
> > > "...order by i.date_from". Is there any way to avoid that from
> > happening?I
> > > am using Deltaspike 1.4.2 but from what I can see in the
> > > OrderByQueryStringPostProcessor source this is still the case in 1.5.4
> > and
> > > also current git master.
> > > Many thanks,Luigi
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
>
>
>
Re: OrderByQueryStringPostProcessor
Posted by Luigi Bitonti <uk...@yahoo.com.INVALID>.
The note reads well, but isn't the example just before it (personRepository.findAllByAge...) inaccurate?
Shouldn't that use .orderAsc("p.lastName", false) and .orderDesc("p.age", false)?
Luigi
On Monday, April 4, 2016 8:07 PM, John D. Ament <jo...@apache.org> wrote:
I added a note to the docs about the extra method
https://deltaspike.apache.org/documentation/data.html#QueryOptions21
If you want to look and give feedback.
John
On Mon, Apr 4, 2016 at 3:02 PM Luigi Bitonti <uk...@yahoo.com.invalid>
wrote:
> Ok, fantastic. Many thanks for that.
> Cheers,Luigi
>
> On Monday, April 4, 2016 5:44 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
> Luigi,
>
> I actually already pushed in a fix.
>
> John
>
> On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <uk...@yahoo.com> wrote:
>
> > Hi John,
> >
> > I've created a fix for this, which you filed as DELTASPIKE-1105. Would
> you
> > accept a patch (as per http://deltaspike.apache.org/community.html) or a
> > pull request?
> >
> > Cheers,
> > Luigi
> >
> >
> >
> > On Thursday, March 31, 2016 12:43 PM, John D. Ament <
> johndament@apache.org>
> > wrote:
> >
> >
> > Hi Luigi,
> >
> > I think really the only way to solve this is to add the methods to
> disable
> > prefixing the entity name. Even adding more attributes to control the
> > entity name won't fix it, as the join problem you described will exist.
> >
> > John
> >
> > On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <uknadors@yahoo.com.invalid
> >
> > wrote:
> >
> > Hi John,
> > Many thanks for your help with this. I am afraid neither of your
> solutions
> > would work for what I can see.
> > What I am currently trying to implement is custom (i.e. client selected)
> > sorting for a jpaql query. Something that looks a bit like this (in a
> > simplified version as the real thing is more complex):
> > SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH
> > bi2.location l WHERE b.organisation = :organisation AND b.timeFrom <
> > :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
> > If I use 'e' instead of 'b' as alias for the Booking entity, everything
> > works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> > cannot order by e.items.id as I get an error (using eclipselink at
> > least) that the attribute cannot be accessed as I should really be using
> > bi2.id, which I cannot use though as that is transformed into e.b2.id.
> > The only solution that I can see would work with every use case I can
> > think of, is to have a way to avoid the 'e' being prepended. This could
> be:
> > 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> > string attribute (i.e. as it is). These could be called orderAscRaw and
> > orderDescRaw or something similar.
> > 2) Alternatively, a similar solution could be that there are overloaded
> > versions of orderAsc(String attribute, boolean useEntityPrefix) and
> > orderDesc. This still adds 2 extra methods to the interface (which is not
> > really great).
> > 3) Using a hint, but for what I can see this would be ugly in my opinion
> > as the hint might be applied after the sorting(s) and therefore the
> > implementation would have to "scan" the query and remove existing 'e'
> > prefixes from the order by clause.
> > I am not a great fan of overloading, so I'd personally go with 1), but I
> > am not sure if this is acceptable or there are better solutions I have
> > overlooked. If it is acceptable I can make the change a create a pull
> > request if that helps.
> > Cheers,Luigi
> >
> > On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> > johndament@apache.org> wrote:
> >
> >
> > Luigi,
> > Actually would you be able to provide the exact query statement you have
> > in your repo. The reason it fails in this test is because the query
> looks
> > like this:
> > @Query("select s from Simple s") public abstract QueryResult<Simple>
> > queryAll();
> > Whereas the identifier is expecting e, in order to work with QueryResult.
> > A similar problem happens with the named query when I change the
> identifier.
> > There's a couple of thoughts I had.1. We can introduce an attribute in
> > query (or even a hint) that says what the identifier is in "select s from
> > Something s". This would be more robust and configurable, but introduce
> a
> > burden.
> > 2. Update documentation to clarify that "e" should be used as your query
> > identifier by default.
> > John
> > On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org>
> > wrote:
> >
> > Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> > John
> >
> > On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com>
> wrote:
> >
> > Hi John,
> > If you add the following test to QueryResultTest.java in
> > deltaspike-data-module:
> > @Test public void should_sort_all_result() { List<Simple>
> > result = repo.queryAll()
> > .orderDesc(Simple_.counter)
> > .orderAsc(Simple_.id) .getResultList(); }
> > You'll get the following error:
> >
> > Tests in error:
> > should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> > org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> > 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple
> s
> > order by e.counter DESC,e.id ASC]
> > This is an overly simplistic case that could be worked around by using
> 'e'
> > as an alias in queryAll (instead of 's'), but in more complex case with
> > joins and order by clauses that use associated entities there's no
> > workaround that I can see.
> > I tried (briefly I must confess) to work around this by creating an
> > alternative QueryBuilderFactory that could then allow me to avoid using
> > WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> > OrderByQueryStringPostProcessor but code duplication made the solution
> > rather ugly, so I gave up and decided to ask.
> > Cheers,Luigi
> > On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> > johndament@apache.org> wrote:
> >
> >
> > Luigi,
> > Do you happen to have a test that can reproduce this?
> > John
> >
> > On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti <uknadors@yahoo.com.invalid
> >
> > wrote:
> >
> > Hi all,
> > I am having issues with using the orderAsc and orderDesc methods on
> > QueryResult as the order by clause always ends up having an "e."
> prepended
> > to its sort-by properties (e.g "...order by e.i.date_from" instead of
> > "...order by i.date_from". Is there any way to avoid that from
> happening?I
> > am using Deltaspike 1.4.2 but from what I can see in the
> > OrderByQueryStringPostProcessor source this is still the case in 1.5.4
> and
> > also current git master.
> > Many thanks,Luigi
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: OrderByQueryStringPostProcessor
Posted by "John D. Ament" <jo...@apache.org>.
I added a note to the docs about the extra method
https://deltaspike.apache.org/documentation/data.html#QueryOptions21
If you want to look and give feedback.
John
On Mon, Apr 4, 2016 at 3:02 PM Luigi Bitonti <uk...@yahoo.com.invalid>
wrote:
> Ok, fantastic. Many thanks for that.
> Cheers,Luigi
>
> On Monday, April 4, 2016 5:44 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
> Luigi,
>
> I actually already pushed in a fix.
>
> John
>
> On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <uk...@yahoo.com> wrote:
>
> > Hi John,
> >
> > I've created a fix for this, which you filed as DELTASPIKE-1105. Would
> you
> > accept a patch (as per http://deltaspike.apache.org/community.html) or a
> > pull request?
> >
> > Cheers,
> > Luigi
> >
> >
> >
> > On Thursday, March 31, 2016 12:43 PM, John D. Ament <
> johndament@apache.org>
> > wrote:
> >
> >
> > Hi Luigi,
> >
> > I think really the only way to solve this is to add the methods to
> disable
> > prefixing the entity name. Even adding more attributes to control the
> > entity name won't fix it, as the join problem you described will exist.
> >
> > John
> >
> > On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <uknadors@yahoo.com.invalid
> >
> > wrote:
> >
> > Hi John,
> > Many thanks for your help with this. I am afraid neither of your
> solutions
> > would work for what I can see.
> > What I am currently trying to implement is custom (i.e. client selected)
> > sorting for a jpaql query. Something that looks a bit like this (in a
> > simplified version as the real thing is more complex):
> > SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH
> > bi2.location l WHERE b.organisation = :organisation AND b.timeFrom <
> > :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
> > If I use 'e' instead of 'b' as alias for the Booking entity, everything
> > works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> > cannot order by e.items.id as I get an error (using eclipselink at
> > least) that the attribute cannot be accessed as I should really be using
> > bi2.id, which I cannot use though as that is transformed into e.b2.id.
> > The only solution that I can see would work with every use case I can
> > think of, is to have a way to avoid the 'e' being prepended. This could
> be:
> > 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> > string attribute (i.e. as it is). These could be called orderAscRaw and
> > orderDescRaw or something similar.
> > 2) Alternatively, a similar solution could be that there are overloaded
> > versions of orderAsc(String attribute, boolean useEntityPrefix) and
> > orderDesc. This still adds 2 extra methods to the interface (which is not
> > really great).
> > 3) Using a hint, but for what I can see this would be ugly in my opinion
> > as the hint might be applied after the sorting(s) and therefore the
> > implementation would have to "scan" the query and remove existing 'e'
> > prefixes from the order by clause.
> > I am not a great fan of overloading, so I'd personally go with 1), but I
> > am not sure if this is acceptable or there are better solutions I have
> > overlooked. If it is acceptable I can make the change a create a pull
> > request if that helps.
> > Cheers,Luigi
> >
> > On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> > johndament@apache.org> wrote:
> >
> >
> > Luigi,
> > Actually would you be able to provide the exact query statement you have
> > in your repo. The reason it fails in this test is because the query
> looks
> > like this:
> > @Query("select s from Simple s") public abstract QueryResult<Simple>
> > queryAll();
> > Whereas the identifier is expecting e, in order to work with QueryResult.
> > A similar problem happens with the named query when I change the
> identifier.
> > There's a couple of thoughts I had.1. We can introduce an attribute in
> > query (or even a hint) that says what the identifier is in "select s from
> > Something s". This would be more robust and configurable, but introduce
> a
> > burden.
> > 2. Update documentation to clarify that "e" should be used as your query
> > identifier by default.
> > John
> > On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org>
> > wrote:
> >
> > Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> > John
> >
> > On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com>
> wrote:
> >
> > Hi John,
> > If you add the following test to QueryResultTest.java in
> > deltaspike-data-module:
> > @Test public void should_sort_all_result() { List<Simple>
> > result = repo.queryAll()
> > .orderDesc(Simple_.counter)
> > .orderAsc(Simple_.id) .getResultList(); }
> > You'll get the following error:
> >
> > Tests in error:
> > should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> > org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> > 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple
> s
> > order by e.counter DESC,e.id ASC]
> > This is an overly simplistic case that could be worked around by using
> 'e'
> > as an alias in queryAll (instead of 's'), but in more complex case with
> > joins and order by clauses that use associated entities there's no
> > workaround that I can see.
> > I tried (briefly I must confess) to work around this by creating an
> > alternative QueryBuilderFactory that could then allow me to avoid using
> > WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> > OrderByQueryStringPostProcessor but code duplication made the solution
> > rather ugly, so I gave up and decided to ask.
> > Cheers,Luigi
> > On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> > johndament@apache.org> wrote:
> >
> >
> > Luigi,
> > Do you happen to have a test that can reproduce this?
> > John
> >
> > On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti <uknadors@yahoo.com.invalid
> >
> > wrote:
> >
> > Hi all,
> > I am having issues with using the orderAsc and orderDesc methods on
> > QueryResult as the order by clause always ends up having an "e."
> prepended
> > to its sort-by properties (e.g "...order by e.i.date_from" instead of
> > "...order by i.date_from". Is there any way to avoid that from
> happening?I
> > am using Deltaspike 1.4.2 but from what I can see in the
> > OrderByQueryStringPostProcessor source this is still the case in 1.5.4
> and
> > also current git master.
> > Many thanks,Luigi
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
Re: OrderByQueryStringPostProcessor
Posted by Luigi Bitonti <uk...@yahoo.com.INVALID>.
Ok, fantastic. Many thanks for that.
Cheers,Luigi
On Monday, April 4, 2016 5:44 PM, John D. Ament <jo...@apache.org> wrote:
Luigi,
I actually already pushed in a fix.
John
On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <uk...@yahoo.com> wrote:
> Hi John,
>
> I've created a fix for this, which you filed as DELTASPIKE-1105. Would you
> accept a patch (as per http://deltaspike.apache.org/community.html) or a
> pull request?
>
> Cheers,
> Luigi
>
>
>
> On Thursday, March 31, 2016 12:43 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
> Hi Luigi,
>
> I think really the only way to solve this is to add the methods to disable
> prefixing the entity name. Even adding more attributes to control the
> entity name won't fix it, as the join problem you described will exist.
>
> John
>
> On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <uk...@yahoo.com.invalid>
> wrote:
>
> Hi John,
> Many thanks for your help with this. I am afraid neither of your solutions
> would work for what I can see.
> What I am currently trying to implement is custom (i.e. client selected)
> sorting for a jpaql query. Something that looks a bit like this (in a
> simplified version as the real thing is more complex):
> SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH
> bi2.location l WHERE b.organisation = :organisation AND b.timeFrom <
> :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
> If I use 'e' instead of 'b' as alias for the Booking entity, everything
> works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> cannot order by e.items.id as I get an error (using eclipselink at
> least) that the attribute cannot be accessed as I should really be using
> bi2.id, which I cannot use though as that is transformed into e.b2.id.
> The only solution that I can see would work with every use case I can
> think of, is to have a way to avoid the 'e' being prepended. This could be:
> 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> string attribute (i.e. as it is). These could be called orderAscRaw and
> orderDescRaw or something similar.
> 2) Alternatively, a similar solution could be that there are overloaded
> versions of orderAsc(String attribute, boolean useEntityPrefix) and
> orderDesc. This still adds 2 extra methods to the interface (which is not
> really great).
> 3) Using a hint, but for what I can see this would be ugly in my opinion
> as the hint might be applied after the sorting(s) and therefore the
> implementation would have to "scan" the query and remove existing 'e'
> prefixes from the order by clause.
> I am not a great fan of overloading, so I'd personally go with 1), but I
> am not sure if this is acceptable or there are better solutions I have
> overlooked. If it is acceptable I can make the change a create a pull
> request if that helps.
> Cheers,Luigi
>
> On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> johndament@apache.org> wrote:
>
>
> Luigi,
> Actually would you be able to provide the exact query statement you have
> in your repo. The reason it fails in this test is because the query looks
> like this:
> @Query("select s from Simple s") public abstract QueryResult<Simple>
> queryAll();
> Whereas the identifier is expecting e, in order to work with QueryResult.
> A similar problem happens with the named query when I change the identifier.
> There's a couple of thoughts I had.1. We can introduce an attribute in
> query (or even a hint) that says what the identifier is in "select s from
> Something s". This would be more robust and configurable, but introduce a
> burden.
> 2. Update documentation to clarify that "e" should be used as your query
> identifier by default.
> John
> On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org>
> wrote:
>
> Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> John
>
> On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com> wrote:
>
> Hi John,
> If you add the following test to QueryResultTest.java in
> deltaspike-data-module:
> @Test public void should_sort_all_result() { List<Simple>
> result = repo.queryAll()
> .orderDesc(Simple_.counter)
> .orderAsc(Simple_.id) .getResultList(); }
> You'll get the following error:
>
> Tests in error:
> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
> order by e.counter DESC,e.id ASC]
> This is an overly simplistic case that could be worked around by using 'e'
> as an alias in queryAll (instead of 's'), but in more complex case with
> joins and order by clauses that use associated entities there's no
> workaround that I can see.
> I tried (briefly I must confess) to work around this by creating an
> alternative QueryBuilderFactory that could then allow me to avoid using
> WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> OrderByQueryStringPostProcessor but code duplication made the solution
> rather ugly, so I gave up and decided to ask.
> Cheers,Luigi
> On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> johndament@apache.org> wrote:
>
>
> Luigi,
> Do you happen to have a test that can reproduce this?
> John
>
> On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti <uk...@yahoo.com.invalid>
> wrote:
>
> Hi all,
> I am having issues with using the orderAsc and orderDesc methods on
> QueryResult as the order by clause always ends up having an "e." prepended
> to its sort-by properties (e.g "...order by e.i.date_from" instead of
> "...order by i.date_from". Is there any way to avoid that from happening?I
> am using Deltaspike 1.4.2 but from what I can see in the
> OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and
> also current git master.
> Many thanks,Luigi
>
>
>
>
>
>
>
>
>
>
>
Re: OrderByQueryStringPostProcessor
Posted by "John D. Ament" <jo...@apache.org>.
Luigi,
I actually already pushed in a fix.
John
On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <uk...@yahoo.com> wrote:
> Hi John,
>
> I've created a fix for this, which you filed as DELTASPIKE-1105. Would you
> accept a patch (as per http://deltaspike.apache.org/community.html) or a
> pull request?
>
> Cheers,
> Luigi
>
>
>
> On Thursday, March 31, 2016 12:43 PM, John D. Ament <jo...@apache.org>
> wrote:
>
>
> Hi Luigi,
>
> I think really the only way to solve this is to add the methods to disable
> prefixing the entity name. Even adding more attributes to control the
> entity name won't fix it, as the join problem you described will exist.
>
> John
>
> On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <uk...@yahoo.com.invalid>
> wrote:
>
> Hi John,
> Many thanks for your help with this. I am afraid neither of your solutions
> would work for what I can see.
> What I am currently trying to implement is custom (i.e. client selected)
> sorting for a jpaql query. Something that looks a bit like this (in a
> simplified version as the real thing is more complex):
> SELECT DISTINCT b FROM Booking b JOIN FETCH b.items bi2 JOIN FETCH
> bi2.location l WHERE b.organisation = :organisation AND b.timeFrom <
> :intervalEnd AND b.timeTo > :intervalStart AND b.status IN :statuses;
> If I use 'e' instead of 'b' as alias for the Booking entity, everything
> works if I only order by attributes of Booking (e.g. e.timeFrom), but I
> cannot order by e.items.id as I get an error (using eclipselink at
> least) that the attribute cannot be accessed as I should really be using
> bi2.id, which I cannot use though as that is transformed into e.b2.id.
> The only solution that I can see would work with every use case I can
> think of, is to have a way to avoid the 'e' being prepended. This could be:
> 1) Adding 2 extra methods to QueryResult that allow to order by a raw
> string attribute (i.e. as it is). These could be called orderAscRaw and
> orderDescRaw or something similar.
> 2) Alternatively, a similar solution could be that there are overloaded
> versions of orderAsc(String attribute, boolean useEntityPrefix) and
> orderDesc. This still adds 2 extra methods to the interface (which is not
> really great).
> 3) Using a hint, but for what I can see this would be ugly in my opinion
> as the hint might be applied after the sorting(s) and therefore the
> implementation would have to "scan" the query and remove existing 'e'
> prefixes from the order by clause.
> I am not a great fan of overloading, so I'd personally go with 1), but I
> am not sure if this is acceptable or there are better solutions I have
> overlooked. If it is acceptable I can make the change a create a pull
> request if that helps.
> Cheers,Luigi
>
> On Thursday, March 31, 2016 1:09 AM, John D. Ament <
> johndament@apache.org> wrote:
>
>
> Luigi,
> Actually would you be able to provide the exact query statement you have
> in your repo. The reason it fails in this test is because the query looks
> like this:
> @Query("select s from Simple s") public abstract QueryResult<Simple>
> queryAll();
> Whereas the identifier is expecting e, in order to work with QueryResult.
> A similar problem happens with the named query when I change the identifier.
> There's a couple of thoughts I had.1. We can introduce an attribute in
> query (or even a hint) that says what the identifier is in "select s from
> Something s". This would be more robust and configurable, but introduce a
> burden.
> 2. Update documentation to clarify that "e" should be used as your query
> identifier by default.
> John
> On Wed, Mar 30, 2016 at 7:50 PM John D. Ament <jo...@apache.org>
> wrote:
>
> Thank you Luigi!I'm able to reproduce, I'll create a ticket.
> John
>
> On Wed, Mar 30, 2016 at 4:59 AM Luigi Bitonti <uk...@yahoo.com> wrote:
>
> Hi John,
> If you add the following test to QueryResultTest.java in
> deltaspike-data-module:
> @Test public void should_sort_all_result() { List<Simple>
> result = repo.queryAll()
> .orderDesc(Simple_.counter)
> .orderAsc(Simple_.id) .getResultList(); }
> You'll get the following error:
>
> Tests in error:
> should_sort_all_result(org.apache.deltaspike.data.impl.QueryResultTest):
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from org.apache.deltaspike.data.test.domain.Simple s
> order by e.counter DESC,e.id ASC]
> This is an overly simplistic case that could be worked around by using 'e'
> as an alias in queryAll (instead of 's'), but in more complex case with
> joins and order by clauses that use associated entities there's no
> workaround that I can see.
> I tried (briefly I must confess) to work around this by creating an
> alternative QueryBuilderFactory that could then allow me to avoid using
> WrappedQueryBuilder, DefaultQueryResult and (ultimately)
> OrderByQueryStringPostProcessor but code duplication made the solution
> rather ugly, so I gave up and decided to ask.
> Cheers,Luigi
> On Wednesday, March 30, 2016 12:32 AM, John D. Ament <
> johndament@apache.org> wrote:
>
>
> Luigi,
> Do you happen to have a test that can reproduce this?
> John
>
> On Tue, Mar 29, 2016 at 5:20 PM Luigi Bitonti <uk...@yahoo.com.invalid>
> wrote:
>
> Hi all,
> I am having issues with using the orderAsc and orderDesc methods on
> QueryResult as the order by clause always ends up having an "e." prepended
> to its sort-by properties (e.g "...order by e.i.date_from" instead of
> "...order by i.date_from". Is there any way to avoid that from happening?I
> am using Deltaspike 1.4.2 but from what I can see in the
> OrderByQueryStringPostProcessor source this is still the case in 1.5.4 and
> also current git master.
> Many thanks,Luigi
>
>
>
>
>
>
>
>
>
>
>