Ok, fantastic. Many thanks for that.
Cheers,Luigi
On Monday, April 4, 2016 5:44 PM, John D. Ament <[email protected]>
wrote:
Luigi,
I actually already pushed in a fix.
John
On Mon, Apr 4, 2016 at 6:35 AM Luigi Bitonti <[email protected]> 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 <[email protected]>
> 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 <[email protected]>
> 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 <
> [email protected]> 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 <[email protected]>
> 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 <[email protected]> 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 <
> [email protected]> 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 <[email protected]>
> 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
>
>
>
>
>
>
>
>
>
>
>
