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 Tue, 05 Apr 2016 08:13:02 GMT
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 <johndament@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 <uknadors@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 <uknadors@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 <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