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 <[email protected]> wrote: > 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 > > > > > > > > > > > > > > > > > > > > > > > > >
