Migrating fetchResults usages

[pglizniewicz]

I have several usages of fetchResults in the code I'm working with. All of these are simple queries (no aggregates, no group bys) with limit and offset set, and I need the count. What am I expected to migrate to these fetchResults calls? Adding Blaze Persistence looks like an overkill for these queries, but I don't see any alternative in QueryDSL. Or should I reuse parts of these queries, first calling them with count, and then with the actual projection I require and limit and offset?

[jwgmeligmeyling]

Its not going to be removed. Just note that there is not any viable way we can solve the bugs you'll eventually run into (whether noticed or not noticed) and that its therefore discouraged to use (without Blaze-Persistence).

[pglizniewicz]

Are there any issues other than multiple group by clauses or the having clause? Is only the code inside the if (getMetadata().getGroupBy().size() > 1 || getMetadata().getHaving() != null) { affected? If that's the problem, then I will simply extend JPAQuery and override the method to throw an exception for this part.

Even if the method won't be deleted, the problem with @Deprecated is it won't work with -Werror builds.

[jwgmeligmeyling]

Just group by and having yes.

Personally I'd just use fetch() and construct the count query separately. Perhaps even write a wrapper around that yourself:

public static <T> QueryResults<T> execute(JPAQuery<T> jpqlQuery, QueryModifiers queryModifiers) {
        return new QueryResults<>(jpqlQuery
                .limit(queryModifiers.getLimit())
                .offset(queryModifiers.getOffset())
                .fetch(), queryModifiers, jpqlQuery.clone().select(Expressions.ONE.count()).fetchOne());
    }

That way you document in your code what the limitations of the count implementation are.

[pglizniewicz]

Thanks, this looks like a nice solution.