deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <>
Subject Re: OrderByQueryStringPostProcessor
Date Thu, 31 Mar 2016 11:43:19 GMT
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.


On Thu, Mar 31, 2016 at 5:35 AM Luigi Bitonti <>

> 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):
> 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 as I get an error (using eclipselink at
> least) that the attribute cannot be accessed as I should really be using
>, which I cannot use though as that is transformed into
> 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 <
>> 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 <>
> 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 <> wrote:
> Hi John,
> If you add the following test to in
> deltaspike-data-module:
>     @Test    public void should_sort_all_result()    {        List<Simple>
> result = repo.queryAll()
>                 .orderDesc(Simple_.counter)
> .orderAsc(                .getResultList();    }
>  You'll get the following error:
> Tests in error:
> should_sort_all_result(
> org.hibernate.hql.internal.ast.QuerySyntaxException: Invalid path:
> 'e.counter' [select s from s
> order by e.counter DESC, 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 <
>> 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 <>
> 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

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