Is it possible (and if so how) to create a criteria query that results in a tuple or array of which some elements are collections from a collection valued property?
Given an entity Dummy which has a List<SubEntities> with name subs
class Dummy {
String name;
List<SubEntity> subs;
}
class SubEntity {
// some attributes
}
I want a criteria API query which results in something with the structure
Tuple>
An Array instead of a Tuple would be fine, same for an Array or similar for List.
I tried the following:
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Object[]> q = cb.createQuery(Object[].class);
Root<DummyEntityWithCollection> root = q.from(DummyEntityWithCollection.class);
Join<Object, Object> subs = root.join("subs");
q.select(cb.array(root.get("name"), subs));
List<Object[]> list = em.createQuery(q).getResultList();
But the Object[]s contained in list have as the second element SubEntitys instead of List<SubEntity>.
This one fails in the same way:
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Tuple> q = cb.createTupleQuery();
Root<DummyEntityWithCollection> root = q.from(DummyEntityWithCollection.class);
Join<Object, Object> subs = root.join("subs");
q.multiselect(root.get("name"), subs);
List<Tuple> list = em.createQuery(q).getResultList();
This variant
CriteriaBuilder cb = em.getCriteriaBuilder();
CriteriaQuery<Object[]> q = cb.createQuery(Object[].class);
Root<DummyEntityWithCollection> root = q.from(DummyEntityWithCollection.class);
q.select(cb.array(root.get("name"), root.get("subs")));
List<Object[]> list = em.createQuery(q).getResultList();
Doesn't work at all and results in an invalid SQL statement with a single . as one select column (at least for Hibernate and HSQLDB).
The question How can I retrieve a collection property using criteria Api seems to indicate that it is not possible but it is based on Hibernate and I would like to get a JPA based answer. Especially an answer pointing out the section of the JPA spec that makes it clear that this is not possible would be appreciated.
JPQL defines the select clause in section 4.8 as
select_clause ::= SELECT [DISTINCT] select_item {, select_item}*
select_item ::= select_expression [[AS] result_variable]
select_expression ::= single_valued_path_expression | scalar_expression | aggregate_expression | identification_variable | OBJECT(identification_variable) | constructor_expression
so you can see that multi-valued expressions are not selectable in JPQL.
Criteria is simply a way to create a query using an API and objects. See JPA spec chapter 6.1:
The semantics of criteria queries are designed to reflect those of Java Persistence query
language queries.
So it's reasonable to assume the same constraint applies to the Criteria API.
Related
Now I am using JPA to access database. I want to get the comments in the specific courses and specific lessons, so the sql would like this:
select * from comment where (commentType, commentId) in (("course", "1"), ("lesson", 2))
I use annotation #Query like this:
#Query("select c from Comment c where (c.commentType, c.commentId) in :attaches")
Page<Comment> findByAttachIn(#Param("attaches") List<String[]> attaches, Pageable pageable);
But finally I got the sql like this:
select * from comment where (commentType, commentId) in (?)
JPA can not translate the array from jql to sql. What shall I do?
An IN expression allows only a single-valued path expressions, so you can't do (commentType, commentId) in in a JPQL query.
JPQL BNF documentation is very clear for the IN part
in_expression ::= {state_field_path_expression | type_discriminator} [NOT] IN { ( in_item {, in_item}* ) | (subquery) | collection_valued_input_parameter }
in_item ::= literal | single_valued_input_parameter
Consequently it can be concluded that you can't do that in JPQL. What you can do is do it manually in the WHERE clause ...
... WHERE (commentType = :type1 AND commentId = :id1) OR
(commentType = :type2 AND commentId = :id2) OR
...
long winded, but gets the answer, and complies with JPQL BNF notation. How you convert standard JPQL into some Spring syntax is left as an exercise to those familiar with that non-standard part
I have three tables one is ItemCategory,ItemMaster and Price. I am referring itemaCategoryId in ItemMaster table and like that referring itemmasterid in price. Now i have to display contents of price order by itemcategory id. This is my criteria query.
CriteriaBuilder cb = entityManager.getCriteriaBuilder();
CriteriaQuery<Price> cq = cb.createQuery(Price.class);
Root<Price> root = cq.from(Price.class);
Root<ItemMaster> itemMasterRoot = cq.from(ItemMaster.class);
Root<ItemCategory> itemCategoryRoot = cq.from(ItemCategory.class);
Join<ItemMaster, ItemCategory> s=itemMasterRoot.join(ItemMaster_.category);
Join<Price,ItemMaster> y=root.join(Price_.itemMaster);
Path<Long> itemMasterId=root.get(Price_.itemMasterId);
cq.select(root).where(cb.equal(root.get(Price_.priceMasterId), priceMasterId))
.orderBy(cb.asc(itemMasterId));
TypedQuery<Price> q = entityManager.createQuery(cq);
Above my criteria Query
If you use multiple from statements, you get the cartesian product of all entities. If you want to preserve the relationships, use join instead:
Root<Price> price = cq.from(Price.class);
Join<Price,ItemMaster> itemMaster = price.join(Price_.itemMaster);
Join<ItemMaster, ItemCategory> itemCategory = itemMaster.join(ItemMaster_.category);
However it looks like at least the second join may be useless, because you are able to access the category property directly using the getter, isn't it?:
Price aPriceResult;
ItemCategory categoryResult = aPriceResult.getItemMaster().getCategory();
I am trying to use the Criteria API instead of constructing queries as JPQL Strings as the Criteria API seems much better suited for this. However, I am having a few problems understanding how to construct the two following statements.
SELECT e
FROM Subject e
WHERE e.company = :c1
OR e.company = :c2
OR e.company = :c3
In this case I need to iterate over an unknown number of values (c1, c2, c3 etc.) to match to the same attribute.
SELECT e
FROM Subject e
WHERE e.company
LIKE :c1
OR e.account
LIKE :c1
OR e.email
LIKE :c1
In this case I need to pass in a single value (c1) and have a 'LIKE' comparison done on a specific range of attributes.
My current pattern looks something like this:
// Criteria
CriteriaBuilder builder = subjectDAO.criteriaBuilder();
CriteriaQuery<Subject> query = builder.createQuery(Subject.class);
// Root
Root<Subject> subject = query.from(Subject.class);
List<Predicate> predicates = new ArrayList();
for (String property : map.keySet()) {
String value = (String) coreFilter.get(map);
predicates.add(????? This is where I come unstuck ?????);
}
// pass all the predicates into the query
query.where(predicates.toArray(new Predicate[predicates.size()]));
NB. I don't have any problems constructing the Query object or specifying the Root or Joins. I am just having problems with the specificity of the above queries. For the sake of clarity just assume that all the attributes are String and don't require any joins.
The expression CriteriaQuery<T> where(Predicate... restrictions), as you can see in the javadoc,
Modify the query to restrict the query result according to the conjunction of the specified restriction predicates.
So, it makes the conjunction of the predicates in the list, i.e. it concatenates them with AND expressions. In order to concatenate them with OR expression, simply use CriteriaBuilder#or(Predicate... restrictions)
query.where(builder.or(predicates.toArray(new Predicate[] {})));
How represent a date in a JPA query, without using (typed) parameters?
If the date is really fixed (for example, 1 mar 1980), the code:
TypedQuery<MyEntity> q = em.createQuery("select myent from db.MyEntity myent where myent.theDate=?1", db.MyEntity.class).setParameter(1, d);
having set:
Date d = new Date(80, Calendar.MARCH, 1);
is quite verbose, isn't it? I would like to embed 1980/1/3 into my query.
UPDATE:
I modified the sample date to 1980/1/3, because 1980/1/1 as it was, was ambiguous.
IIRC you can use date literals in JPQL queries just like you do it in JDBC, so something like:
// d at the beginning means 'date'
{d 'yyyy-mm-dd'} i.e. {d '2009-11-05'}
// t at the beginning means 'time'
{t 'hh-mm-ss'} i.e. {t '12-45-52'}
// ts at the beginning means 'timestamp'; the part after dot is optional
{ts 'yyyy-mm-dd hh-mm-ss.f'} i.e. {ts '2009-11-05 12-45-52.325'}
should do the work (the curly braces and apostrophes are required).
I spent a couple days digging around on this. Seems the root of the problem is that the Hibernate generated grammar does not include support for temporal literals.
The JPA specification does include support for temporal literals but does not require persistence providers to translate from from the JPA syntax to the native syntax of the JDBC driver. From the JPA2 Spec 4.6.1:
"The JDBC escape syntax may be used for the specification of date, time, and timestamp literals. For example:
SELECT o
FROM Customer c JOIN c.orders o
WHERE c.name = 'Smith'
AND o.submissionDate < {d '2008-12-31'}
The portability of this syntax for date, time, and timestamp literals is dependent upon the JDBC driver in use. Persistence providers are not required to translate from this syntax into the native syntax of the database or driver."
It would be nice if Hibernate did provide support for date literals, but it seems the implementation for this is a little more involved that I'd suspected.
The functionality lacking here as far as my needs are concerned is that you cannot do a select coalesce(somePath, someDateLiteral) query. You can still do a where somePath=someDate. As long as they're mapped entities you can throw whatever you want in a where clause.
I used criteriaQuery for my querys, its just great. It looks like:
#Override
public List<Member> findAllByDimensionAtTime(Dimension selectedDimension,
Date selectedDate) {
CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
CriteriaQuery<Member> criteriaQuery = criteriaBuilder
.createQuery(Member.class);
Root<Member> member = criteriaQuery.from(Member.class);
criteriaQuery
.select(member)
.where(criteriaBuilder.lessThanOrEqualTo(
member.get(Member_.validFrom), selectedDate),
criteriaBuilder.greaterThanOrEqualTo(
member.get(Member_.validTo), selectedDate),
criteriaBuilder.equal(
member.get(Member_.myDimensionId),
selectedDimension.getId())).distinct(true);
return em.createQuery(criteriaQuery).getResultList();
validFrom and validTo are date fields!
Edit: shorter Example (according to yours):
CriteriaBuilder criteriaBuilder = em.getCriteriaBuilder();
CriteriaQuery<MyEntity> criteriaQuery = criteriaBuilder
.createQuery(MyEntity.class);
Root<MyEntity> entity= criteriaQuery.from(MyEntity.class);
criteriaQuery
.select(member)
.where(criteriaBuilder.equal(
entity.get(MyEntity_.theDate),
new Date(80, Calendar.MARCH, 1);)).distinct(true);
return em.createQuery(criteriaQuery).getResultList();
I have a query with a self join that looks like this,
select t1., t2. from table t1
left outer join table t2 on t2.LFT < t1.LFT
and t2.RGT > t1.RGT
AND t2.REG_CODE_PAR = 'ALL'
AND t1.STATUS_CODE = 'A'
AND t2.STATUS_CODE = 'A'
I'm using #NamedNativeQuery with a result set mapping to get the result.
#NamedNativeQuery(
name="findTree",
query="..... the query above",
resultSetMapping = "regionT")
With the following result set mapping
#SqlResultSetMapping(name = "regionT" , entities ={
#EntityResult(
entityClass = Tree.class
fields = {
#FieldResult(name = "regCode", column = "REG_CODE")
#FieldResult(name = "rgt", column = "RGT"),
#FieldResult(name = "lft", column = "LFT"),
#FieldResult(name = "name", column = "NAME"),
#FieldResult(name = "regCodePar", column = "REG_CODE_PAR"),
#FieldResult(name = "statusCode", column = "STATUS_CODE")
}
),
#EntityResult(
entityClass = TreeSelf.class
fields = {
#FieldResult(name = "regCode1", column = "REG_CODE")
#FieldResult(name = "rgt1", column = "RGT"),
#FieldResult(name = "lft1", column = "LFT"),
#FieldResult(name = "name1", column = "NAME"),
#FieldResult(name = "regCodePar1", column = "REG_CODE_PAR"),
#FieldResult(name = "statusCode1", column = "STATUS_CODE")
}
)
})
The entity class contains looks like this.
#NamedNativeQuery(...)
#SqlResultSetMapping(...)
#Entity
#Table(name = "table")
public class Tree implements Serializable {
#Id
#Column(name = "REG_CODE")
private String regCode; ... ..getters and setters...}
When I run the query using em.createQuery("findTree"), I get the exact same object in both
the 1st and 2nd elements of the returned object array.
Even if I create a class called TreeSelf that is identical to Tree and use it as the 2nd
EntityResult instead of having 2 EntityResults using the same entityClass, I get the same
result.
Can someone point out what's wrong with the configuration?
Let's see if I understand your question. You're expecting to capture two Tree entities from each native query result row. The first entity should be formed from t1's columns. The second entity should be formed from t2's columns. Contrary to expectation, you actually receive two instances formed from t1. No instances from t2 appear. You made a doppelganger Entity for Tree called TreeSelf while debugging, but TreeSelf is ultimately unnecessary and you want to get rid of it. Stop me if any of that was wrong.
I think the problem is due to ambiguous column names. Each column name in the native query appears twice, once from t1 and once from t2. The result mapper seems to be arbitrarily picking the first occurrence of each ambiguous column name for both Tree entities. I'm surprised that works at all. I would have expected an SQLException complaining about column reference ambiguity.
Also, are you sure you want a left outer join? What if no match is found for a t1 row? It will be paired with all NULL in t2's columns. Then you have a null-valued Tree entity. I think. I don't even know what the result mapper would do in that case. Perhaps you want an inner join?
Consider translating this native query into a JPQL query. (JPA Criteria API is just as well, but I find it more cumbersome for examples.) Here's a JPQL version of the native query:
SELECT t1, t2
FROM Tree t1, Tree t2
WHERE t2.lft < t1.lft AND t2.rgt > t1.rgt AND t2.regCodePar = 'ALL' AND
t1.statusCode = 'A' AND t2.statusCode = 'A'
N.B.: This changes the join semantics to inner instead of left outer.
Here's a sketch of code that could run this query:
EntityManager em = ... // EntityManager by injection, EntityManagerFactory, etc.
String jpql = ... // Like example above
TypedQuery<Object[]> q = em.createQuery(jpql, Object[].class);
for (Object[] oa : q.getResultList()) {
Tree t1 = (Tree)oa[0];
Tree t2 = (Tree)oa[1];
}
In case you are stuck with the native query for whatever reason, here's how you can work around the column name ambiguity. Instead of starting the native query like select t1.*, t2.*, alias each column with AS. The SELECT clause would resemble this:
SELECT t1.REG_CODE AS t1_REG_CODE, t1.RGT AS t1_RGT, (... rest of t1 cols ...),
t2.REG_CODE AS t2_REG_CODE, t2.RGT AS t2_RGT, (... rest of t2 cols ...)
The column attribute in each FieldResult must change accordingly. So the column attributes under the first EntityResult should all start with t1_ and the second's should all start with t2_.
I'd humbly recommend deleting the native query and sql result mapper and using JPA Query Language or Criteria API, if you can find a way.
Update: As confirmed in your comments, a useful answer to your question must preserve left (outer) join semantics. Unfortunately, JPQL and the Criteria API don't support complex left join conditions. There is no way to qualify a JPQL left join with an explicit ON condition.
To my knowledege, the only way to do a left outer join under the spec is by traversing an entity relationship. The JPA implementation then generates an ON condition that tests identity equality. The relevant spec bits are 4.4.5 "Joins" and 4.4.5.2 "Left Outer Joins".
To satisfy this constraint, each Tree you want to left-join to its ultimate parent must have an additional column storing the ultimate parent's id. You might be able to cheat around this constraint in a variety of ways (views?). But the path of least resistance seems to be modifying the native query to use aliased arguments, deleting TreeSelf, and updating the result mapper accordingly. Cleverer solutions welcome, though...