[Hibernate-JIRA] Updated: (HHH-1088) Add support for projections using composite keys and components
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
Gail Badner updated HHH-1088:
-----------------------------
Issue Type: Improvement (was: Bug)
Summary: Add support for projections using composite keys and components (was: IdentifierProjection does not work with composite keys)
> Add support for projections using composite keys and components
> ---------------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate Core
> Issue Type: Improvement
> Components: query-criteria
> Affects Versions: 3.1 rc2
> Reporter: Max Muermann
> Assignee: Gail Badner
> Fix For: 3.5.0.Next
>
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[Hibernate-JIRA] Created: (HHH-5034) Make CriteriaImpl.uniqueResult() more robust
by Tomas Pollak (JIRA)
Make CriteriaImpl.uniqueResult() more robust
--------------------------------------------
Key: HHH-5034
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5034
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Reporter: Tomas Pollak
We are using Sybase for generating a query that has a COUNT(*) and ORDER BY. Granted, the 'order by' doesn't have any semantic effect, but it's a dynamically generated query, and we need to know the total count as well as the actual result.
The problem is that Sybase returns many rows for such a query, and the uniqueResult() fails with a NonUniqueResultException. Although every returned row contains an Integer with the same value, they are different instances.
We could modify the AbstractQueryImpl.uniqueElement(List list) as follows:
static Object uniqueElement(List list) {
int size = list.size();
if (size == 0) return null;
Object first = list.get(0);
for (int i = 1; i < size; i++) {
if (!safeEquals(first, list.get(i))) {
throw new NonUniqueResultException(list.size());
}
}
return first;
}
static boolean safeEquals(Object first, Object second) {
if (first instanceof Integer && second instanceof Integer) {
return ((Integer)first).compareTo((Integer)second) == 0;
}
return first == second;
}
That would solve our issue.
Thanks.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months
[Hibernate-JIRA] Created: (HHH-5009) Support NOWAIT for "SELECT ... FOR UPDATE" with JPA interfaces
by Sergey Vladimirov (JIRA)
Support NOWAIT for "SELECT ... FOR UPDATE" with JPA interfaces
--------------------------------------------------------------
Key: HHH-5009
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5009
Project: Hibernate Core
Issue Type: Improvement
Affects Versions: 3.5.0-CR-2
Environment: Oracle / Derby
Reporter: Sergey Vladimirov
Test case description:
- DERBY dialect extended to add /* +NOWAIT */ SQL comment to check if it's actually used.
- if it's working, log should contain
--- "org.hibernate.SQL DEBUG select entity0_.id as id0_0_, entity0_.value as value0_0_ from entities entity0_ where entity0_.id=? for update with rs /* +NOWAIT */"
-- but currently it
--- "org.hibernate.SQL DEBUG select entity0_.id as id0_0_, entity0_.value as value0_0_ from entities entity0_ where entity0_.id=? for update with rs"
It seems LockOptions (like "javax.persistence.lock.timeout") are lost when converting from JPA to Hibernate. The possible place of error, from my point of view, is loadFromDatasource() (DefaultLoadEventListener:499), where persister is loaded depending only on LockMode without paying attention to lockOptions (including timeout).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 3 months