November 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

19 years, 5 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HBX-811) Integrate with Eclipse code formatting

by Max Rydahl Andersen (JIRA)

Integrate with Eclipse code formatting -------------------------------------- Key: HBX-811 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-811 Project: Hibernate Tools Type: New Feature Components: ant Versions: 3.2beta8 Reporter: Max Rydahl Andersen Fix For: 3.2beta9 eclipse 3.2 code formatter can be used standalone; lets provide integration with it from ant and possibly run it automatically on java code hibernate tools generate -- 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

19 years, 5 months

1
3
0 / 0

[Hibernate-JIRA] Commented: (HBX-656) nvarchar2

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-656?page=co... ] Max Rydahl Andersen commented on HBX-656: ----------------------------------------- more or less yes. > nvarchar2 > --------- > > Key: HBX-656 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-656 > Project: Hibernate Tools > Type: Improvement > Components: reverse-engineer > Versions: 3.1.beta5 > Environment: Oracle 10g release 2 > Reporter: Francois Jean > Fix For: 3.2beta9 > > > Hello, > When using Oracle with columns of type NVARCHAR2, the reverse engineering tool maps the columns with a java attribute of type Serializable. We would prefer to have these columns mapped to String. However NVARCHAR2 has no corresponding JDBC type, so recognizing this type by Java would imply to verify the JDBC type and if the JDBC type is unknown then verify the type name and if it's VARCHAR2 than map it to String. Do you think it's a possible solution? > For now, we are doing the following in the reverse-eng.xml file, but it's not very neat since it maps all the "OTHER" types to String: > <type-mapping> > <sql-type jdbc-type="OTHER" hibernate-type="String" /> > </type-mapping> > Link on Oracle listing the unsupported Oracle type: > http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/apxref.... > Link explaining the use of String with NVARCHAR2: > http://download-east.oracle.com/docs/cd/B19306_01/java.102/b14355/global.... > François Jean -- 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

19 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1564) deleting versioned object with collection leads to unecessary update

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1564?page=all ] Steve Ebersole updated HHH-1564: -------------------------------- Summary: deleting versioned object with collection leads to unecessary update (was: Possible bug with deleting versioned object (patch included)) > deleting versioned object with collection leads to unecessary update > -------------------------------------------------------------------- > > Key: HHH-1564 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1564 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.2 > Environment: 3.1rc2 > Reporter: N Clayton > Assignee: Steve Ebersole > Fix For: 3.2.1 > Attachments: onetomanydelete_test.tar.gz > > > We're seeing an odd problem when trying to delete a row. The code that does this simply creates a new object, commits it, starts a new session, finds the object, deletes it. It dies with a constraint violation on an audit table, because hibernate is issuing an unnecessary update operation (and not incrementing the version either). Further debugging shows that Hibernate thinks that three properties on the object are 'modified'. These three are collections. One is the points collection, one owners and the other is systems. Hibernate seems to think that they are 'different' because null != an empty collection. So, it thinks it needs to update the object. However; later on - it doesn't increment the version number - because it knows the object is to be deleted. Thus - a problem. > A complete description is here: > http://forum.hibernate.org/viewtopic.php?t=950225&highlight=collectiontyp... > This appears to be fixed if we change CollectionType.isDirty() to be: > public boolean isDirty(Object old, Object current, boolean[] checkable, SessionImplementor session) > throws HibernateException { > if(checkable.length == 0) { > // Assume not checkable > return false; > } > return isDirty(old, current, session); > } -- 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

19 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HBX-816) hibernatetool ant task should fail when encountering errors

by Uwe Kubosch (JIRA)

hibernatetool ant task should fail when encountering errors ----------------------------------------------------------- Key: HBX-816 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-816 Project: Hibernate Tools Type: Bug Components: ant Versions: 3.2beta8 Environment: Hibernate 3.2 Reporter: Uwe Kubosch When using the hibernatetool ant task to generate the database schema, I sometimes get errors. in these cases the task should fail and stop the ant script. Today the task reports the errors in stdout and stderr, but continues. -- 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

19 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2237) Oracle driver and BLOB types fail in real world scenario

by Magesh Kumar Bojan (JIRA)

Oracle driver and BLOB types fail in real world scenario -------------------------------------------------------- Key: HHH-2237 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2237 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga Environment: JBoss AS 4.0.4 GA, JBoss Portal 2.4 GA Reporter: Magesh Kumar Bojan Attachments: test.log When JBoss Portal is started up using Oracle 10g (10.2.0.1) and using the Oracle JDBC driver (version 10.2.0.2), and using the JBoss Portal CMS module, if you upload a file, it throws IOExceptions. The file size is arbitrary and should be more than 100KB. Some of the IOExceptions thrown are and not limited to: java.sql.SQLException: Io exception: Bad file descriptor and java.sql.BatchUpdateException: Io exception: Read error Please use the attached test.log for testing. There is a workaround for this as in you can modify the BlobImpl like this and it works: public BlobImpl(InputStream stream, int length) { byte[] bytes = new byte[length]; try { stream.read(bytes,0,length); } catch (IOException e) { e.printStackTrace(); } finally { try { stream.close(); } catch (IOException e) { //ignore } } this.stream = new ByteArrayInputStream(bytes); this.length = bytes.length; } This code is not optimized, but for those who feel they need an urgent fix, this works! -- 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

19 years, 5 months

3
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses

by Olaf Lenzmann (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c... ] Olaf Lenzmann commented on HHH-1460: ------------------------------------ Wonderful - thanks a lot for the quick fix! > Inconsistent behavior when using Session.get() with multiple subclasses > ----------------------------------------------------------------------- > > Key: HHH-1460 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.2 > Environment: Hibernate 3.1.2 > HSQLDB 1.8.0.2 > Java 1.5.0_05-b05 > Reporter: Seth Fitzsimmons > Assignee: Steve Ebersole > Fix For: 3.2.1 > Attachments: ClassCastException.zip > > > Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected). When attempting to load it without prior loading, null is returned, as expected. > Client and Partner both extend person and have discriminator values of 1 and 2, respectively. There is a single entry in the database (a Client) with a PK of 0. > This should be null: > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); > It is. However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist: > Client client = (Client) getSession().get(Client.class, 0); > assertNotNull(client); > > // this should be null, not return a Client object (resulting in a ClassCastException) > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); -- 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

19 years, 5 months

1
0
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

19 years, 5 months

3
9
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=all ] Steve Ebersole resolved HHH-1460: --------------------------------- Fix Version: 3.2.1 Resolution: Fixed Assign To: Steve Ebersole > Inconsistent behavior when using Session.get() with multiple subclasses > ----------------------------------------------------------------------- > > Key: HHH-1460 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.2 > Environment: Hibernate 3.1.2 > HSQLDB 1.8.0.2 > Java 1.5.0_05-b05 > Reporter: Seth Fitzsimmons > Assignee: Steve Ebersole > Fix For: 3.2.1 > Attachments: ClassCastException.zip > > > Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected). When attempting to load it without prior loading, null is returned, as expected. > Client and Partner both extend person and have discriminator values of 1 and 2, respectively. There is a single entry in the database (a Client) with a PK of 0. > This should be null: > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); > It is. However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist: > Client client = (Client) getSession().get(Client.class, 0); > assertNotNull(client); > > // this should be null, not return a Client object (resulting in a ClassCastException) > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); -- 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

19 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c... ] Steve Ebersole commented on HHH-1460: ------------------------------------- Actually, in thinking about this some more, this should be consistent. My comment before was simply that the correct behavior here is clearly to throw an exception. I mean, this is simply stupid: Animal a = new Dog(); Cat c = ( Cat ) a; // now c is magically set to null It is difficult to change the scenario where get() leads to the entity being loaded from the database such that it throws a CCE. So I'll change this to return null. Then you can deal with the "consistent behavior" in your code ;) > Inconsistent behavior when using Session.get() with multiple subclasses > ----------------------------------------------------------------------- > > Key: HHH-1460 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.2 > Environment: Hibernate 3.1.2 > HSQLDB 1.8.0.2 > Java 1.5.0_05-b05 > Reporter: Seth Fitzsimmons > Attachments: ClassCastException.zip > > > Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected). When attempting to load it without prior loading, null is returned, as expected. > Client and Partner both extend person and have discriminator values of 1 and 2, respectively. There is a single entry in the database (a Client) with a PK of 0. > This should be null: > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); > It is. However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist: > Client client = (Client) getSession().get(Client.class, 0); > assertNotNull(client); > > // this should be null, not return a Client object (resulting in a ClassCastException) > Partner partner = (Partner) getSession().get(Partner.class, 0); > assertNull(partner); -- 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

19 years, 5 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2006