Generic solution to Hibernate's CriteriaQuery

Code Review Asked by stefan.georgiev.uzunov on September 23, 2020

I’ve created a little class which helps me to generalize many query cases. I have a DbService and couple methods in it. Can you please take a look at it and share some criticism? The usage of that tool is really easy to me and I do wanna know how to make it safer and optimized.

 public class DbServiceImpl implements DbService {
 private final EntityManager entityManager;

 DbServiceImpl(EntityManager entityManager) {
    this.entityManager = entityManager;

 public <T, V> List<V> createQuery(Query<T, V> query) {
    try {
        if (query != null && query.entityType.getAnnotation(Entity.class) != null) {
            CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();

            CriteriaQuery<V> criteriaQuery = criteriaBuilder.createQuery(query.returnType);

            query.root = criteriaQuery.from(query.entityType);
            query.builder = criteriaBuilder;

            Selection<? extends V> selection =; //invokes on the call.
            Predicate predicate = query.where(); 

            if (predicate != null) {
                criteriaQuery.where(predicate); //null of a simple select without where clause.

  ; //null is allowed, it will just select * from the entity

            return entityManager.createQuery(criteriaQuery).getResultList();
      } catch (Exception exception) {
    return new ArrayList<>(); //a simple check of .isEmpty() covers that case.

 public abstract static class Query<T, V> {
    private final Class<T> entityType;
    private final Class<V> returnType;

    //accessible only by outer class's methods.
    private Root<T> root; 
    private CriteriaBuilder builder; 

    public Query() {
        this.entityType=(Class<T>) ((ParameterizedType) getClass()
        this.returnType=(Class<V>) ((ParameterizedType) getClass()

    protected abstract Selection<? extends V> select();

    protected abstract Predicate where();

    protected Root<T> root() {
        return root;

    protected CriteriaBuilder builder() {
        return builder;

And here are some use cases. Passed types are as follows – entity & return (User,Long)

  List<Long> data = dbService.createQuery(new DbServiceImpl.Query<User, Long>() {
        protected Selection<? extends Long> select() {
            return builder().count(root());
        protected Predicate where() {
            return root();

This allows me to find the count of a table so understandable, without a line of pure HQL or any SQL code. One more example:

  List<User> users = dbService.createQuery(new DbServiceImpl.Query<User, User>() {
        protected Selection<? extends User> select() {
            return root();

        protected Predicate where() {
            return builder().equal(root().get("username"), username);

One with a join:

    List<Recipe> recipeList= dbService.createQuery(new DbServiceImpl.Query<Recipe, Recipe>() {
        protected Selection<? extends Recipe> select() {
            return null;

        protected Predicate where() {
            root().fetch("author", JoinType.LEFT);
            return builder().equal(root().get("author").get("id"),user.getId());

The code structure remains the same but the query is different. The access modifiers I used allowed me to encapsulate the behaviour on the use cases. What do you think? How broken or useful is that?

One Answer

Welcome to Code Review, I have seen your code and I have seen you encapsulated your createQuery method like below:

try { body method } catch (Exception exception) { exception.printStackTrace(); }

You are basically catching all NullPointerException cases and other runtime exceptions you can meet within your method with the Exception class, this is a sign something should be redesigned to avoid these situations.

About the paradigm you are following , you are implementing a personal version of the repository pattern, referring to structures like the jpa repository present for example in the spring framework. You can check while you are creating different queries worrying about the construction of a valid query (and this is the reason why you had to encapsulate your method in the try catch construct), it should be better using an already built class to do the same things with much less effort.

Answered by dariosicily on September 23, 2020

Add your own answers!

Related Questions

C++ linked list inheriting from node class

1  Asked on November 17, 2021 by devinthenrough


MMMRjs a product of BYTES Genesis

3  Asked on November 17, 2021 by syed-mohammad-sannan


Simple marker rendering

1  Asked on November 17, 2021


C++20 ScopeGuard

1  Asked on November 15, 2021


LeetCode 37: Sudoku Solver

1  Asked on November 13, 2021


Converting a float to a fraction as a string

1  Asked on November 11, 2021 by stonkilla4


C# consecutive and redundant null checks

6  Asked on November 11, 2021 by frederik-hoeft


Format string processing similar to date or printf()

2  Asked on November 11, 2021 by domsson


Improvement to Luhn-Checksum Algorithm in Java

2  Asked on November 11, 2021 by elauser


Full Adder in Verilog

1  Asked on November 8, 2021


Python palindrome checker function

4  Asked on November 8, 2021 by dicomp


Ask a Question

Get help from others!

© 2022 All rights reserved. Sites we Love: PCI Database, MenuIva, UKBizDB, Menu Kuliner, Sharing RPP, SolveDir