deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luigi Bitonti <uknad...@yahoo.com.INVALID>
Subject Re: OrderByQueryStringPostProcessor
Date Mon, 04 Apr 2016 10:35:19 GMT
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 <johndament@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 <uknadors@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 






  


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