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 > > > > > > > > > > >
