Criteria API

Criteria API and HQL are both used to query data from a database in Hibernate, but they have some differences:

• Criteria API is a type-safe and object-oriented way to build queries, while HQL is a string-based query language.
• Criteria API queries are created using a set of predefined classes and methods, while HQL queries are written as strings.
• Criteria API queries are checked for syntax errors at compile-time, while HQL queries are checked at runtime.
• Criteria API queries can be easily modified and extended programmatically, while HQL queries require modifying the string query itself.

Sure! Here's an example of using Criteria API to retrieve all the books published after a certain date:

CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();
CriteriaQuery criteriaQuery = criteriaBuilder.createQuery(Book.class);
Root bookRoot = criteriaQuery.from(Book.class);

Predicate predicate = criteriaBuilder.greaterThan(bookRoot.get("publishDate"), LocalDate.of(2022, 1, 1));
criteriaQuery.where(predicate);

List books = entityManager.createQuery(criteriaQuery).getResultList();

There are several advantages of using Criteria API:

• Type-safety: Criteria API queries are checked for syntax errors at compile-time, reducing the chances of runtime errors.
• Object-oriented: Criteria API provides a more natural and intuitive way to build queries using classes and methods, making the code easier to read and maintain.
• Dynamic queries: Criteria API queries can be easily modified and extended programmatically, allowing for dynamic filtering and sorting of data.
• Reusability: Criteria API queries can be encapsulated into reusable methods or criteria builders, promoting code reuse.
• Integration with JPA: Criteria API is part of the JPA (Java Persistence API) specification, making it compatible with other JPA implementations.

Criteria API is preferred over HQL in the following scenarios:

• Dynamic queries: If the query needs to be dynamically constructed based on runtime conditions, Criteria API provides a more flexible and readable way to build such queries.
• Type-safety: If type-safety is a concern, Criteria API ensures that the query is checked for syntax errors at compile-time.
• Object-oriented approach: If the development team prefers an object-oriented approach for building queries, Criteria API provides a more natural and intuitive way to do so.
• Integration with JPA: If the application is using JPA as the persistence framework, Criteria API is a better choice as it is part of the JPA specification and provides better compatibility.

Sure! Here's an example of a complex query using Criteria API:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Employee.class);
Root employee = query.from(Employee.class);

// Selecting employees with salary greater than 50000
query.select(employee)
    .where(cb.greaterThan(employee.get("salary"), 50000));

// Executing the query
List result = entityManager.createQuery(query).getResultList();

To perform join operations using Criteria API, you can use the join() method provided by the CriteriaQuery and Root classes. The join() method allows you to specify the join type (inner, left, right) and the join condition. Here's an example:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Employee.class);
Root employee = query.from(Employee.class);
Join department = employee.join("department");

// Selecting employees and their department names
query.multiselect(employee.get("name"), department.get("name"));

// Executing the query
List result = entityManager.createQuery(query).getResultList();

While Criteria API provides a powerful way to construct complex queries, it also has some limitations. Here are a few limitations:

1. Lack of support for complex subqueries: Criteria API does not provide direct support for complex subqueries, such as nested subqueries or correlated subqueries. To handle such scenarios, you may need to resort to native SQL queries or other query languages.

2. Limited support for dynamic queries: Although Criteria API allows you to build dynamic queries, it can be cumbersome to construct complex queries with dynamic conditions or joins. In such cases, using JPQL or native SQL queries may be more convenient.

3. Steep learning curve: Criteria API has a steep learning curve compared to JPQL or native SQL queries. It requires understanding of the CriteriaQuery, CriteriaBuilder, and other related classes, which may take some time to grasp.

Despite these limitations, Criteria API remains a powerful tool for constructing complex queries in a type-safe and programmatic manner.

Sure! Here's an example of using Projections in Criteria API to retrieve specific columns:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Object[].class);
Root root = query.from(Employee.class);

query.select(cb.array(root.get("name"), root.get("salary")));

List results = entityManager.createQuery(query).getResultList();

for (Object[] result : results) {
    String name = (String) result[0];
    BigDecimal salary = (BigDecimal) result[1];
    // Process the data
}

There are several types of Projections available in Criteria API:

1. Projections.property(String propertyName): Retrieves a specific property of an entity.
2. Projections.alias(Projection projection, String alias): Assigns an alias to a projection.
3. Projections.rowCount(): Retrieves the count of rows in the result set.
4. Projections.sum(Expression> expression): Calculates the sum of a numeric expression.
5. Projections.avg(Expression> expression): Calculates the average of a numeric expression.
6. Projections.max(Expression> expression): Retrieves the maximum value of an expression.
7. Projections.min(Expression> expression): Retrieves the minimum value of an expression.
8. Projections.groupProperty(String propertyName): Groups the result set by a specific property.
9. Projections.distinct(Projection projection): Retrieves distinct values of a projection.

Projections in Criteria API can be used to perform aggregation operations such as sum, average, maximum, minimum, and grouping. Here's an example of using Projections to calculate the sum of salaries for each department:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Object[].class);
Root root = query.from(Employee.class);

Expression sumSalary = cb.sum(root.get("salary"));
Expression department = root.get("department");

query.select(cb.array(department, sumSalary));
query.groupBy(department);

List results = entityManager.createQuery(query).getResultList();

for (Object[] result : results) {
    String departmentName = (String) result[0];
    BigDecimal totalSalary = (BigDecimal) result[1];
    // Process the data
}

Sure! Here's an example of pagination using Criteria API:

CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();
CriteriaQuery criteriaQuery = criteriaBuilder.createQuery(Entity.class);
Root root = criteriaQuery.from(Entity.class);

criteriaQuery.select(root);
criteriaQuery.orderBy(criteriaBuilder.asc(root.get("id")));

int pageNumber = 1;
int pageSize = 10;
int firstResult = (pageNumber - 1) * pageSize;

TypedQuery query = entityManager.createQuery(criteriaQuery);
query.setFirstResult(firstResult);
query.setMaxResults(pageSize);

List entities = query.getResultList();

The methods used in Criteria API for pagination are:

• setFirstResult(int firstResult): Specifies the index of the first result to retrieve.
• setMaxResults(int maxResults): Specifies the maximum number of results to retrieve.

There are several advantages of using pagination in Criteria API:

1. Performance: Pagination allows retrieving only a subset of results, which can improve query performance by reducing the amount of data transferred.
2. User Experience: Pagination provides a better user experience by breaking down large result sets into smaller, more manageable pages.
3. Memory Efficiency: By retrieving results in chunks, pagination helps conserve memory resources.
4. Scalability: Pagination enables handling large result sets without overwhelming system resources.
5. Flexibility: Pagination allows users to navigate through result sets and view specific subsets of data.

Sure! Here's an example of using Restrictions in Criteria API to add a condition for selecting entities with a specific value:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Entity.class);
Root root = query.from(Entity.class);

query.select(root)
    .where(cb.equal(root.get("property"), "value"));

List entities = entityManager.createQuery(query).getResultList();

There are several types of Restrictions available in Criteria API, including:

• equal: Adds an equality condition
• notEqual: Adds a not-equal condition
• like: Adds a like condition
• notLike: Adds a not-like condition
• isNull: Adds a null condition
• isNotNull: Adds a not-null condition
• gt: Adds a greater-than condition
• lt: Adds a less-than condition
• ge: Adds a greater-than-or-equal condition
• le: Adds a less-than-or-equal condition
• between: Adds a between condition
• in: Adds an in condition
• notIn: Adds a not-in condition

These are just a few examples, and there are more types of Restrictions available depending on the Criteria API implementation.

Restrictions in Criteria API can be used to perform conditional operations by combining them using logical operators such as and, or, and not. For example, to add multiple conditions using and, you can use the and method of the CriteriaBuilder class:

CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery query = cb.createQuery(Entity.class);
Root root = query.from(Entity.class);

Predicate condition1 = cb.equal(root.get("property1"), "value1");
Predicate condition2 = cb.equal(root.get("property2"), "value2");

query.select(root)
    .where(cb.and(condition1, condition2));

List entities = entityManager.createQuery(query).getResultList();