October 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2027) ComponentType.replace reverts interceptor's changes to null component

by Josh Moore (JIRA)

ComponentType.replace reverts interceptor's changes to null component --------------------------------------------------------------------- Key: HHH-2027 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2027 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate r10347 java version "1.5.0_07" Reporter: Josh Moore Attachments: nullcomponentinterceptor.zip When an interceptor sets a previously null component-typed property of an entity to a non-null value, ComponentType.replace reverts the value to null due to the lines 422-425: if ( original == null ) { return null; } This means it is not possible on Interceptor.onSave() to "fix" a null component even if true is returned. Excerpts from the attached zip file follow: [MAPPING] <class name="Image" table="image" abstract="false" select-before-update="true"> <id name="id" type="java.lang.Long" column="id"><generator class="native"/></id> <component name="details" class="Details"> <property name="perm1" not-null="true" type="long" column="permissions"/> </component> <property name="name" type="java.lang.String" column="name" not-null="true" length="256"/> </class> [INTERCEPTOR] public class DetailsInterceptor extends EmptyInterceptor { boolean onSaveCalled = false; @Override public boolean onSave(Object entity, Serializable id, Object[] state, String[] propertyNames, Type[] types) { state[0] = new Details(); onSaveCalled = true; return true; } } [TEST] DetailsInterceptor pi = new DetailsInterceptor(); Session s = openSession( pi ); Transaction t = s.beginTransaction(); Image i = new Image(); i.setName("compincomp"); // the interceptor does the equivalent of: // // i.setDetails( new Details() ); // // which when uncommented makes this test pass. // // without that line, the null details gets copied back to the result // on merge causing the following on commit: /* org.hibernate.PropertyValueException: not-null property references a null or transient value: org.hibernate.test.compincomp.Image.details at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72) at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:263) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:121) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:195) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) */ s.merge(i); assertTrue( pi.onSaveCalled ); t.commit(); s.close(); -- 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

18 years, 10 months

2
5
0 / 0

[Hibernate-JIRA] Created: (EJB-222) Add "remove" cascading style to CascadeStyle for XML mappings

by Christian Bauer (JIRA)

Add "remove" cascading style to CascadeStyle for XML mappings ------------------------------------------------------------- Key: EJB-222 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-222 Project: Hibernate Entity Manager Type: Improvement Components: EntityManager Reporter: Christian Bauer Currently the AnnotationBinder translates a JPA CascadeType.REMOVE as follows: case REMOVE: cascade.append( "," ).append( "delete" ); However, if I use XML mapping files I have to use cascade="delete" to get the same effect. A practical example why this is very inconvenient for users, documentation, etc: I want to translate the following annotation mapping to XML: @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REMOVE}) I end up with: <set name="foo" cascade="persist, merge, delete"> I recommend adding "remove" as an alias for "delete" to the map in engine/CascadeStyle.java -- 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

18 years, 10 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2178) When the sql statement submited to create the PreparedStatement contains comments, MySQL misunderstand it (and doubles the parameter count).

by Diogenes Gomes (JIRA)

When the sql statement submited to create the PreparedStatement contains comments, MySQL misunderstand it (and doubles the parameter count). -------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2178 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2178 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: MySQL 3.2.0 Reporter: Diogenes Gomes Priority: Trivial When I used the following Hibernate properties: hibernate.format_sql=true hibernate.use_sql_comments=true I found a bug in QueryLoader.java in method prepareQueryStatement: ... sql = preprocessSQL( sql, queryParameters, dialect ); PreparedStatement st = null; if (callable) { st = session.getBatcher() .prepareCallableQueryStatement( sql, scroll || useScrollableResultSetToSkip, scrollMode ); } else { st = session.getBatcher() .prepareQueryStatement( sql, scroll || useScrollableResultSetToSkip, scrollMode ); } ... Before running preprocessSQL, the value of the local variable 'sql' was: "select ... from ... where formulario0_.ffw_nome=?" After running preprocessSQL, the value of 'sql' was: "/* from ... where form.nome = ? */ select ... from ... where formulario0_.ffw_nome=?" The value of st.parameterCount after running session.getBatcher().prepareQueryStatement(...) was 2 (may be because of the double ? in the sql statement). And I got a SQLException: "No value specified for parameter 2". When I set both variables to false, it runs ok. The st.parameterCount is 1 and no exception. -- 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

18 years, 10 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2138) merge with bidirectional one-to-one may fail

by Emmanuel Bernard (JIRA)

merge with bidirectional one-to-one may fail -------------------------------------------- Key: HHH-2138 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2138 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr5 Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard -- 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

18 years, 10 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2162) Optimisitic Locking unusable with 1..N of Set or List

by Olli Blackburn (JIRA)

Optimisitic Locking unusable with 1..N of Set or List ----------------------------------------------------- Key: HHH-2162 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2162 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: Core 3.2 GA EM 3.2 GA HSQLDB 1.8.0.2 in memory Reporter: Olli Blackburn Priority: Blocker Attachments: Playpen.zip Calling merge() on an unmodified entity with 1..N relationship using Set or List results in the entity being marked dirty, its version number is increased and an SQL UPDATE performed on it. This makes it impossible to achieve any kind of sensible concurrency in our application which makes extensive use of detached objects. See the attached test case (packaged as a complete eclipse 3.2 project). Set EJB3_HOME, HIBERNATE_HOME and HSQLDB_HOME in your eclipse workspace preferences and then run the included PojoTest launcher to see it run. The test populates the DB, does a select by name, merge, merge and select by name again. Each of these five steps is in its own Tx and entity manager. The test is repeated for Set, Map and List. Interesting Map seems to work, but as our application doesn't use Maps that's little comfort to us. The pojo is not being modified (by my code) between the merge calls(), yet I get the following output (each print is before the commit following the operation): findByUniqueName: PojoHashSet4 version=2 merge: PojoHashSet4 version=2 merge: PojoHashSet4 version=3 findByUniqueName: PojoHashSet4 version=5 findByUniqueName: PojoHashMap4 version=0 merge: PojoHashMap4 version=0 merge: PojoHashMap4 version=0 findByUniqueName: PojoHashMap4 version=0 findByUniqueName: PojoArrayList4 version=0 merge: PojoArrayList4 version=0 merge: PojoArrayList4 version=1 findByUniqueName: PojoArrayList4 version=2 HHH-1401 and HHH-1668 seem like they might be related to my problem, but debugging my test case shows otherwise. The problem seems to be caused by the replacement of the empty collection with a new empty collection. More specifically, the empty target collection is cleared, marking it dirty, even though it contains no members is is about to have nothing copied in it. This occurs in org.hibernate.type.CollectionType.replaceElements(). Looking at the code paths I think the problem runs deeper than my empty collection case. If the source and target being copied by replaceElements() are identical (whether zero length or not), the target will be marked dirty due to the result.clear() call in replaceElements(). It seems there needs to be a pre-check for this case to avoid the whole clear and copy process with it's associated setting of "dirtiness". I'm attaching a patch for CollectionType which fixes the problem in the testing we've performed. Feedback and comments appreciated. -- 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

18 years, 10 months

6
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2185) introduce setting to control cglib caching of classes

by Max Rydahl Andersen (JIRA)

introduce setting to control cglib caching of classes ----------------------------------------------------- Key: HHH-2185 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2185 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Reporter: Max Rydahl Andersen Priority: Trivial Fix For: 3.2.1 As discussed in http://forum.hibernate.org/viewtopic.php?p=2327620#2327620 the current default behavor of disable cglib's cache of classes is a problem in the case of many sessionfactories for the same pojo's. -- 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

18 years, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2127) Document <filter-def condition="defaultCondition"> and <filter-def>defaultCondition

by Emmanuel Bernard (JIRA)

Document <filter-def condition="defaultCondition"> and <filter-def>defaultCondition ----------------------------------------------------------------------------------- Key: HHH-2127 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2127 Project: Hibernate3 Type: Improvement Components: documentation Reporter: Emmanuel Bernard Fix For: 3.2.1 -- 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

18 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2135) Hibernate Deserialization: In org.hibernate.type.SerializableType the code makes a test for the return of a null object by simply testing the object as to whether or not it is null.

by Lamon Gray (JIRA)

Hibernate Deserialization: In org.hibernate.type.SerializableType the code makes a test for the return of a null object by simply testing the object as to whether or not it is null. -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2135 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2135 Project: Hibernate3 Type: Improvement Versions: 3.2.0.cr5 Environment: HIbernate 3.2.1 & NCR TeradataJBOss 4.0.x & JBoss Cache 1.2.4 Reporter: Lamon Gray In org.hibernate.type.SerializableType the code makes a test for the return of a null object by simply testing the object as to whether or not it is null. public Object get(ResultSet rs, String name) throws HibernateException, SQLException { byte[] bytes = (byte[]) Hibernate.BINARY.get(rs, name); if ( bytes==null) { return null; } else { return fromBytes(bytes); } } Fairly reasonable, however in my testing of the Teradata dialect i am finding that often the value in the column is null but that the return is coming back as an empty array. The following code would seem to be a bit more robust in my opinion: public Object get(ResultSet rs, String name) throws HibernateException, SQLException { byte[] bytes = (byte[]) Hibernate.BINARY.get(rs, name); if ( bytes==null || Array.getLength(bytes)==0) { return null; } else { return fromBytes(bytes); } } Can someone tell me if this is done this way for a reason? Or maybe the JDBC driver is returning the incorrect value (IE. it should be returning a null value as opposed to an empty array)? -- 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

18 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HBX-795) Entity documentation is missing hierarchy information

by Mark Hobson (JIRA)

Entity documentation is missing hierarchy information ----------------------------------------------------- Key: HBX-795 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-795 Project: Hibernate Tools Type: Improvement Components: hbm2doc Versions: 3.2beta8 Reporter: Mark Hobson Attachments: patch.txt The attached patch adds the entity hierarchy tree to the entity page as per javadoc. -- 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

18 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HBX-784) Hibernate Tools 3.2.0b8 seems to disregard some reveng directives

by Michael T. (JIRA)

Hibernate Tools 3.2.0b8 seems to disregard some reveng directives ----------------------------------------------------------------- Key: HBX-784 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-784 Project: Hibernate Tools Type: Bug Components: reverse-engineer Versions: 3.2beta8 Environment: Hibernate version: 3.2.0GA Hibernate tools version: 3.2.0.b8 Java Version: 1.5.0.7 Eclipse Version: 3.2.1 Postgres: 8.0 w/ JDBC driver 8.1b407 (Recreated with MySQL 5.0 and MySQL/J 5.0) Reporter: Michael T. Attachments: revengsimplecase.zip I have a legacy database that unfortunately uses "class" as a table name and there are several tables that refer to this table. I've created a reveng.xml through the tools interface that I believe should rename the "class" object to TFARClass and members of referring classes to tfarClass. When I build the classes, the "TFARClass" object is created but all the referencing classes still have members called "class", which obviously doesn't work. I've attached a simple workspace that recreates the issue. The attached SQL is for MySQL 5.0 and creates two tables (class and classrange) that have two columns each. There is no functioning code in the workspace, just the hibernate configuration, console and reveng files as well as the class files that were created. -- 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

18 years, 11 months

2
1
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2006