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
