[Hibernate-JIRA] Created: (HHH-2626) Bug in handling null references to Components / Embeddables when using session / entityManager.merge()
by Michael Plöd (JIRA)
Bug in handling null references to Components / Embeddables when using session / entityManager.merge()
------------------------------------------------------------------------------------------------------
Key: HHH-2626
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2626
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.3 - 3.2.4.sp1; Any Database
Reporter: Michael Plöd
Priority: Critical
Attachments: patch.txt, TestCase.zip
I found a bug, that got introduced by adding functionality to the class TypeFactory in Hibernate 3.2.3. The Method TypeFactory#replaceAssociations(...) now has some special handling regarding components / embeddables. But if such a component is null, wich is fair enough, Hibernate will provoke a NullPointerException in sun.reflect.UnsafeFieldAccessorImpl.ensureObj(...):
Exception in thread "main" javax.persistence.PersistenceException: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of de.ploed.test.MonetaryAmount.amount
at org.hibernate.ejb.AbstractEntityManagerImpl.throwPersistenceException(AbstractEntityManagerImpl.java:647)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:236)
at de.ploed.test.EntityManagerTest.main(EntityManagerTest.java:22)
Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of de.ploed.test.MonetaryAmount.amount
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:35)
at org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValue(AbstractComponentTuplizer.java:64)
at org.hibernate.tuple.component.AbstractComponentTuplizer.getPropertyValues(AbstractComponentTuplizer.java:70)
at org.hibernate.tuple.component.PojoComponentTuplizer.getPropertyValues(PojoComponentTuplizer.java:83)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:353)
at org.hibernate.type.ComponentType.getPropertyValues(ComponentType.java:348)
at org.hibernate.type.TypeFactory.replaceAssociations(TypeFactory.java:556)
at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:366)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:195)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:123)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:53)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:227)
... 1 more
Caused by: java.lang.NullPointerException
at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:36)
at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:18)
at java.lang.reflect.Field.get(Field.java:357)
at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:32)
... 15 more
I think that the handling of target[i] in Line 556 of org.hibernate.type.TypeFactory is not null safe. I have created a patch for this and the bug above appears to be fixed in this patch.
In my humble opinion this bug makes it impossible to merge any entity / value object containing a null reference to another value object.
However this bug is not present when using session.save or session.saveOrUpdate.
I was able to reproduce the bug in Hibernate Core 3.2.4.sp1, 3.2.4 and 3.2.3 .. It is not present in Hibernate Core Versions <= 3.2.2
Attached to this task are the following files:
patch.txt - my patch proposal
TestCase.zip - Test Case
Please get back to me if you have any further questions!
Cheers,
Mike
--
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
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2488) Resolution of filters' conditions should be postponed till all mappings are loaded.
by Dmitry Katsubo (JIRA)
Resolution of filters' conditions should be postponed till all mappings are loaded.
-----------------------------------------------------------------------------------
Key: HHH-2488
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2488
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: Hibernate-Version: 3.2.2.ga
Java(TM) SE Runtime Environment (build 1.6.0-b105)
Reporter: Dmitry Katsubo
When trying to use the possibility to define the conditions for the same filters in {{<filter-def>}}, the following exception occurs, as the resolution of conditions should be done at a later stage, after all mappings are loaded:
{noformat}
Exception in thread "main" java.lang.NullPointerException
at org.hibernate.cfg.HbmBinder.parseFilter(HbmBinder.java:2931)
at org.hibernate.cfg.HbmBinder.bindCollection(HbmBinder.java:1462)
at org.hibernate.cfg.HbmBinder$2.create(HbmBinder.java:2757)
{noformat}
The example of definition, that uses filters:
{code:xml|title=clauses.hbm.xml|borderStyle=solid}
<class name="ClauseFolderImpl" table="stc_folders">
<id name="id">
<generator class="native" />
</id>
<property name="name" not-null="true" />
<property name="private" not-null="true" />
<set name="subFolders" outer-join="false" cascade="none">
<key column="parentId" />
<one-to-many class="ClauseFolderImpl" />
<filter name="folderFilterLimited" />
<filter name="folderFilter" />
</set>
<filter name="folderFilterLimited" />
<filter name="folderFilter" />
</class>
<filter-def name="folderFilterLimited" condition="(parentId is null or (languageId = :languageId and procedureTypeId = :procedureTypeId))" >
<filter-param name="languageId" type="int" />
<filter-param name="procedureTypeId" type="int" />
</filter-def>
<filter-def name="folderFilter" condition="(parentId is null or private = :isPrivate)">
<filter-param name="isPrivate" type="boolean" />
</filter-def>
{code}
As Hibernate ues DTD to check the validity of configuration file, the {{<filter-def>}} definitions can't be moved to the beginning of the configuration file. The possible walkaround is to define filters in another file, and include it first:
{code:xml|title=hibernate-configuration.xml|borderStyle=solid}
<hibernate-configuration>
<session-factory>
...
<mapping resource="filters.hbm.xml"/> <!-- only filter-def's here -->
<mapping resource="clauses.hbm.xml"/>
...
</session-factory>
</hibernate-configuration>
{code}
Relative issue is [http://opensource.atlassian.com/projects/hibernate/browse/HHH-1182#action... HHH-1182].
--
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
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2189) Left Outer Join Conditions
by yann degat (JIRA)
Left Outer Join Conditions
--------------------------
Key: HHH-2189
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2189
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.1.3
Reporter: yann degat
Priority: Blocker
Attachments: OracleJoinFragment.java, OracleJoinFragment.java
the "org.hibernate.sql.OracleJoinFragment.addLeftOuterJoinCondition"
does not take the "!=" operator into account.
it places the "(+)" like this "!(+)=" instead of " (+) !="
( != is a valid operator for Oracle )
and it returns (+)<(+)> for the '<>' operator
here's a patch. (maybe not the best one )
/**
* This method is a bit of a hack, and assumes
* that the column on the "right" side of the
* join appears on the "left" side of the
* operator, which is extremely wierd if this
* was a normal join condition, but is natural
* for a filter.
*/
private void addLeftOuterJoinCondition(String on) {
StringBuffer buf = new StringBuffer( on );
for ( int i = 0; i < buf.length(); i++ ) {
char character = buf.charAt( i );
boolean isInsertPoint = OPERATORS.contains( new Character( character ) ) ||
( character == ' ' && buf.length() > i + 3 && "is ".equals( buf.substring( i + 1, i + 4 ) ) ) ;
if( character == '<' && buf.length() > i + 1 && ">".equals( buf.substring( i + 1, i + 2 ) ) ){
isInsertPoint = false;
buf.insert( i, "(+)" );
i += 3 + 2;
}
if ( isInsertPoint ) {
buf.insert( i, "(+)" );
i += 3;
}
if( character == '!' && buf.length() > i + 1 && "=".equals( buf.substring( i + 1, i + 2 ) ) ){
buf.insert( i, "(+)" );
i += 3 + 2;
}
}
addCondition( buf.toString() );
}
--
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
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2503) AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
by Dag Liodden (JIRA)
AbstractEntityPersister swallows JDBCExceptions in processGeneratedProperties
-----------------------------------------------------------------------------
Key: HHH-2503
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2503
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.2, 3.2.3
Environment: 3.2.2GA and trunk
Reporter: Dag Liodden
Seems to be a small typo on line 3718 in AbstractEntityPersister (trunk and 3.2.2 GA) which makes exceptions during property generation being logged but not thrown:
catch( SQLException sqle ) {
JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
There should be a throw in there I guess. :)
catch( SQLException sqle ) {
throw JDBCExceptionHelper.convert(
getFactory().getSQLExceptionConverter(),
sqle,
"unable to select generated column values",
selectionSQL
);
This bug will not be noticeable in most cases and is probably why it hasn't been detected / fixed so far. The method in question (processGeneratedProperties) is used for retrieving properties that are marked as "generated" in the mapping document / annotations - in other words any value that the database provides and is considered "read-only" from the Hibernate application's point of view.
The generated value is retrieved by an extra select statement executed by Hibernate after an entity has been inserterd and / or updated (according to how the generated property is flagged). In my particular case, a property (not a key) is marked as generated="insert", so after Hibernate inserts a new entity to the database, it will immediately do a select and set the generated property to the value the database returns.
Only in rare cases will this select fail in any way - in fact, I cannot think of any situations other than mapping errors (e.g getInt on a CHAR column) that can cause errors in this last select. That is in addition to my situation - a deadlock.
My entity class uses uuid.hex generator for the PK, but at one point, we introduced a second unique key due to purely aestethic reasons. This is a SQL Server identity column. Since we don't do any explicit table locking during the inserts, we end up with deadlocks every time the following happens:
T1: INSERT INTO TABLE (ID) values (?)
T2: INSERT INTO TABLE (ID) values (?)
T2: SELECT GENERATED_ID FROM TABLE WHERE ID = ? -- T1's insert hasn't been committed, so what should the the generated ID be? Deadlock!
T1: SELECT GENERATED_ID FROM TABLE WHERE ID = ?
...
SQL Server throws an error to indicate the deadlock, but due to the missing throw in the processGeneratedProperties-method, it is never shown to the process doing the insert. The generated property is not set and retains it's null (or 0 in case of a primitive) without the business logic ever knowing that the entity could not be saved.
--
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
17 years, 4 months
[Hibernate-JIRA] Created: (HHH-2320) Regression: optional properties under a <join> tag no longer update properly
by Chris Jones (JIRA)
Regression: optional properties under a <join> tag no longer update properly
----------------------------------------------------------------------------
Key: HHH-2320
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2320
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.0.cr4, 3.2.0.ga, 3.2.0.cr5
Environment: hibernate 3.2.0.cr4 through 3.2.1.ga
hsql 1.8.0.7 and Oracle 9i
Reporter: Chris Jones
This was specifically introduced with the revision 10217 changes on the 3.2 branch in src/org/hibernate/persister/entity/AbstractEntityPersister.java
Given the following setup:
<class name="Thing">
<id .../>
<join table="JOIN_TABLE" optional="true">
<key column="THING_ID" not-null="true"/>
<property name="joinedProperty" column="JOINED_PROPERTY"/>
</join>
</class>
scenario:
Thing thing1 = new Thing();
thing1.setJoinedProperty("thing1");
save(thing1);
// a record in the JOIN_TABLE is created properly and updates on the property can occur
Thing thing2 = new Thing();
thing2.setJoinedProperty(null);
save(thing2);
// no record in JOIN_TABLE is created
thing2.setJoinedProperty("thing2");
save(thing2);
// in revision 10216, hibernate correctly runs an INSERT to create a JOIN_TABLE record with the value "thing2"
// in revision 10217, hibernate incorrectly runs an UPDATE to try and update a non-existant record in the JOIN_TABLE with the thing2 id
It looks like the expectation.verifyOutcome() method should be throwing a StaleStateException if the attempted update effects 0 rows.
I will try and get an official hibernate testcase going and possibly a patch, but I wanted to enter this now in case there is something I'm missing that makes this change in functionality intentional.
--
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
17 years, 4 months