deltaspike-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John D. Ament" <johndam...@apache.org>
Subject Re: OrderByQueryStringPostProcessor
Date Thu, 07 Apr 2016 02:06:51 GMT
Ah yes good point.  Fixed.

On Tue, Apr 5, 2016 at 4:13 AM Luigi Bitonti <uknadors@yahoo.com.invalid>
wrote:

> 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