[Hibernate-JIRA] Created: (HHH-3958) Superfluous generated updates cause Violation of UNIQUE KEY constraint
by Guenther Demetz (JIRA)
Superfluous generated updates cause Violation of UNIQUE KEY constraint
----------------------------------------------------------------------
Key: HHH-3958
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3958
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: 3.3.1 GA, SQLServer 2008
Reporter: Guenther Demetz
Priority: Minor
Attachments: Testcase.jar
When deleting a entire closure of objects associated over @ManyToOne within one single transaction, then on commit
the FlushEventListener creates update statements on objects which are going to be deleted anyway.
These update statements seems not only be useless,
in certain scenarios they lead to Constraint Violation Exceptions, see the example here:
@Entity
public class A {
public A() { }
@Id @GeneratedValue
private long oid;
}
@Entity
@Table(uniqueConstraints = {@UniqueConstraint(columnNames={"assA_oid"})})
public class B {
public B() {};
@Id @GeneratedValue
private long oid;
@javax.persistence.ManyToOne
protected A assA = null;
}
A a1 = new A(); em.persist(a1);
A a2 = new A(); em.persist(a2);
B b1 = new B();
b1.assA = a1; // set unique association
B b2 = new B();
b2.assA = a2; // set unique association
em.persist(b1);
em.persist(b2);
em.getTransaction().commit();
em.getTransaction().begin();
em.remove(a1);
em.remove(a2);
em.remove(b1);
em.remove(b2);
em.getTransaction().commit();
// p6spy report:
// update B set assA_oid='',version=0 where oid=1 and version=0
// update B set assA_oid='',version=0 where oid=2 and version=0 --> this raises "Violation of UNIQUE KEY constraint on all DB's which don't allow multiple null values in a unique index
See testcase in attachment
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-4030) Implement support for native recursive query functionality of popular DBMSes
by David Cracauer (JIRA)
Implement support for native recursive query functionality of popular DBMSes
----------------------------------------------------------------------------
Key: HHH-4030
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4030
Project: Hibernate Core
Issue Type: New Feature
Components: core, query-hql, query-sql
Environment: Hibernate 3.3.2, MSSQL
Reporter: David Cracauer
We have a couple of areas in our system where need to load tree structures from our database. These trees can be very deep (often 20+ levels). SQL Server 2005 introduced Common Table Expressions, a kind of in-line view that can be used recursively.
These allow us to quickly get a result set like this:
id, label, parentId
1, foo, null
2, foo2, 1
3, foo3, 2
4, foo4, 2
5, foo5, 4
6, foo6, 1
>From a tree like this:
[1, foo]
|
| -[2, foo2]
| | - [3, foo3]
| | - [4, foo4]
| | - [5, foo5]
|- [6, foo6]
using a query like this (not tested):
with MyCTE(
id,
label,
parentId)
as
( select n.id, n.label, n.parentid
from Node n
UNION ALL
select c.id, c.label, c.parentId
from MyCTE c
inner join Node n on n.id=c.parentId)
select * from MyCTE
It happens many times more quickly than we've been able to load the graphs with Hibernate, even using batching etc.
We've tried using hibernate's built in native sql support without success. The alias injection breaks the Common Table Expression definition ( with MyCTE ), as it is a view definition and doesn't allow for the 'id as id_276' syntax, rather requiring just a column name.
I know that there are several other major DBMSes that support recursive querying now. Is there a way to have support for this functionality in hibernate core?
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-3961) SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT
by Guenther Demetz (JIRA)
SQLServerDialect, support nowait in LockMode.UPGRADE_NOWAIT
------------------------------------------------------------
Key: HHH-3961
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3961
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.3.1
Environment: 3.3.1 GA , SQLServer2008
Reporter: Guenther Demetz
Priority: Trivial
The method SQLServerDialect#appendLockHint currently ignores the LockMode.UPGRADE_NOWAIT returning the same string as for
LockMode.UPGRADE.
public String appendLockHint(LockMode mode, String tableName) {
if ( mode.greaterThan( LockMode.READ ) ) {
// does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)";
return tableName + " with (updlock, rowlock)";
}
else {
return tableName;
}
}
As SQLServer supports the nowait option I propose the following improvement:
public String appendLockHint(LockMode mode, String tableName) {
if ( mode == LockMode.UPGRADE_NOWAIT) {
return tableName + " with (updlock, rowlock, nowait)";
}
else if ( mode.greaterThan( LockMode.READ ) ) {
// does this need holdlock also? : return tableName + " with (updlock, rowlock, holdlock)";
return tableName + " with (updlock, rowlock)";
}
else {
return tableName;
}
}
A test gave me a correct behaviour: if the concerning row is already locked,
then after Lock request time out period exceeded following exception is thrown:
org.hibernate.exception.SQLGrammarException: could not lock: [persistent.jpa.AssociationsClassPeer#1]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:115)
at org.hibernate.persister.entity.AbstractEntityPersister.lock(AbstractEntityPersister.java:1361)
at org.hibernate.event.def.AbstractLockUpgradeEventListener.upgradeLock(AbstractLockUpgradeEventListener.java:108)
at org.hibernate.event.def.DefaultLockEventListener.onLock(DefaultLockEventListener.java:87)
at org.hibernate.impl.SessionImpl.fireLock(SessionImpl.java:611)
at org.hibernate.impl.SessionImpl.lock(SessionImpl.java:603)
...
Caused by: com.microsoft.sqlserver.jdbc.SQLServerException: Lock request time out period exceeded.
at com.microsoft.sqlserver.jdbc.SQLServerException.makeFromDatabaseError(SQLServerException.java:196)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet$FetchBuffer.nextRow(SQLServerResultSet.java:4700)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.fetchBufferNext(SQLServerResultSet.java:1683)
at com.microsoft.sqlserver.jdbc.SQLServerResultSet.next(SQLServerResultSet.java:956)
at com.p6spy.engine.spy.P6ResultSet.next(P6ResultSet.java:156)
at com.p6spy.engine.logging.P6LogResultSet.next(P6LogResultSet.java:124)
at com.mchange.v2.c3p0.impl.NewProxyResultSet.next(NewProxyResultSet.java:2859)
at org.hibernate.dialect.lock.SelectLockingStrategy.lock(SelectLockingStrategy.java:97)
... 24 more
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-3718) call to id getter initializes proxy when using AccessType( "field" )
by Paul Lorenz (JIRA)
call to id getter initializes proxy when using AccessType( "field" )
--------------------------------------------------------------------
Key: HHH-3718
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3718
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Environment: hibernate 3.3.1, hibernate annotations 3.4.0, running on windows, linux and solaris, using sybase 15
Reporter: Paul Lorenz
Calling getter for id when using AccessType( "field" ) causes proxy initialization.
In org.hibernate.proxy.proxy.pojo.BasicLazyInitializer there is the code
else if ( isUninitialized() && method.equals(getIdentifierMethod) ) {
return getIdentifier();
}
However, when using field access, the getIdentifierMethod will be null. I fixed this for us by changing DirectPropertyAccessor by adding a Method attribute to the DirectGetter inner class, and looking up the appropriate getter in the constructor. As far as I can tell, getMethod is only used in two places. In the above case, to the get the identity getter and in PojoComponentTupilizer.isMethodOf. This doesn't seem to break anything. I don't know if this is a clean solution, seems a little hacky to me, however, it would be great if the issue could be fixed somehow.
public static final class DirectGetter implements Getter {
private final transient Field field;
private final Class clazz;
private final String name;
private Method method;
DirectGetter(Field field, Class clazz, String name) {
this.field = field;
this.clazz = clazz;
this.name = name;
try
{
BeanInfo beanInfo = Introspector.getBeanInfo( clazz );
PropertyDescriptor[] pdArray = beanInfo.getPropertyDescriptors();
if ( pdArray != null )
{
for (PropertyDescriptor pd : pdArray )
{
if ( pd.getName().equals( name ) )
{
this.method = pd.getReadMethod();
}
}
}
}
catch ( Exception e )
{
// ignore
}
}
public Object get(Object target) throws HibernateException {
try {
return field.get(target);
}
catch (Exception e) {
throw new PropertyAccessException(e, "could not get a field value by reflection", false, clazz, name);
}
}
public Object getForInsert(Object target, Map mergeMap, SessionImplementor session) {
return get( target );
}
public Method getMethod() {
return method;
}
public String getMethodName() {
return method == null ? null : method.getName();
}
public Class getReturnType() {
return field.getType();
}
Object readResolve() {
return new DirectGetter( getField(clazz, name), clazz, name );
}
public String toString() {
return "DirectGetter(" + clazz.getName() + '.' + name + ')';
}
}
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-5160) Error on binding values prepared statment in many-to-any relation
by wof (JIRA)
Error on binding values prepared statment in many-to-any relation
-----------------------------------------------------------------
Key: HHH-5160
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5160
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.1, 3.3.2
Environment: Tested on Version 3.3.2 and 3.5.1 on Oracle, PostgreSQL and MySQL
Reporter: wof
A Collection of Entities is defined as a ManyToAny relation, e.g.
@ManyToAny(metaColumn=@Column(name="C_OBJECT_TYPE"))
@AnyMetaDef(idType="string", metaType="string",
metaValues={
@MetaValue(targetEntity=Entity1.class, value="Entity1"),
@MetaValue(targetEntity=Entity2.class, value="Entity2")
})
@JoinTable(name="T_OBJECTS",
joinColumns=@JoinColumn(name="C_OWNER_ID"),
inverseJoinColumns=@JoinColumn(name="C_OBJECT_ID")
)
private Set<EntityBase> objects = new HashSet<EntityBase>();
Adding to this set works without problems. Removing all elements from the set (i.e. setting the set to null or zero-sized), too. However, when one or more elements are removed from the set with at least one element remaining, an exception is thrown:
org.hibernate.exception.GenericJDBCException: could not delete collection rows with the cause being java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2).
I have narrowed this problem to this: The mapping table consists of 3 columns, C_OWNER_ID, C_OBJECT_TYPE and C_OBJECT_ID. The generated SQL-statement to delete the rows is as folling:
DELETE FROM t_objects WHERE c_owner_id=? AND c_object_id=?
However, Hibernate (in org.hibernate.typ.AnyType) tries to bind the actual value for c_object_id with index 3 which causes the exception. I guess Hibernate expects c_object_type to be present in the statement.
As workaround we changed nullSafeSet in AnyType to:
public void nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session)
throws HibernateException, SQLException {
Serializable id;
String entityName;
if (value==null) {
id=null;
entityName=null;
}
else {
entityName = session.bestGuessEntityName(value);
id = ForeignKeys.getEntityIdentifierIfNotUnsaved(entityName, value, session);
}
// metaType is assumed to be single-column type
// <ORIGINAL CODE>
/*
if ( settable==null || settable[0] ) {
metaType.nullSafeSet(st, entityName, index, session);
}
if (settable==null) {
identifierType.nullSafeSet(st, id, index+1, session);
}
else {
boolean[] idsettable = new boolean[ settable.length-1 ];
System.arraycopy(settable, 1, idsettable, 0, idsettable.length);
identifierType.nullSafeSet(st, id, index+1, idsettable, session);
}
*/
// </ORIGINAL CODE>
// <PATCHED CODE>
if ( settable==null || settable[0] ) {
metaType.nullSafeSet(st, entityName, index, session);
boolean[] idsettable = new boolean[ settable.length-1 ];
System.arraycopy(settable, 1, idsettable, 0, idsettable.length);
identifierType.nullSafeSet(st, id, index+1, idsettable, session);
}
else if (settable==null) {
identifierType.nullSafeSet(st, id, index+1, session);
}
else {
boolean[] idsettable = new boolean[ settable.length-1 ];
System.arraycopy(settable, 1, idsettable, 0, idsettable.length);
identifierType.nullSafeSet(st, id, index, idsettable, session);
}
// </PATCHED CODE>
}
best regards
wof
--
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
12 years, 6 months