June 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5908) unnecessary updates when using select-before-update dirty check with entity that has immutable many-to-one properties.

by Howard Kelsey (JIRA)

unnecessary updates when using select-before-update dirty check with entity that has immutable many-to-one properties. ---------------------------------------------------------------------------------------------------------------------- Key: HHH-5908 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5908 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.1, 3.6.0 Reporter: Howard Kelsey Priority: Critical Attachments: update-testcase.zip Entities with many-to-one properties that have insert="false" update="false" are always marked as dirty! This is because when creating the sqlSnapshotSelectString in AbstractEntityPersister.getPropertyUpdateability() is used to identify which properties should be returned in that select and immutable many-to-one props are not. The AbstractEntityPersister.findModified(Object[] old, Object[] current, Object entity, SessionImplementor session) is used to work out if the object has in fact changed, however AbstractEntityPersister.propertyColumnUpdateable is always used to determine which properties are to be checked which means that immutable many-to-one properties are checked even though they're not returned by snapshot select. This is a side effect of the change made for HHH-2350 which changed ManyToOne.isAlwaysDirtyChecked to always return true. So I think it should be changed so that when comparing with the DB snapshot only the properties returned by the AbstractEntityPersister.sqlSnapshotSelectString should be checked by using AbstractEntityPersister.getPropertyUpdateability() instead of AbstractEntityPersister.propertyColumnUpdateable -- 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, 11 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5901) transient fields are persisted

by Frank Griffin (JIRA)

transient fields are persisted ------------------------------ Key: HHH-5901 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5901 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.0 Environment: JBoss 6.0.0.Final using Hypersonic Reporter: Frank Griffin Attachments: DBUtDVDTitleEntityBean.java This is virtually identical to ANN-132, which was marked as FIXED in 3.1. The attached entity bean (DBUtDVDTitleEntityBean) has a "private transient Object oDisks" field. The field is not annotated as @Transient, and the orm.xml does not have a <transient> (or any other) element for the field. According to spec, the "transient" java attribute should exempt it from persistence. However, if you deploy the EAR containing this Entity Bean, the error {noformat} Caused by: org.hibernate.MappingException: property mapping has wrong number of columns: org.profsoftsvcs.dbutils.DVD.DBUtDVDTitleEntityBean.disks type: object at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:464) [:3.6.0.Final] at org.hibernate.mapping.RootClass.validate(RootClass.java:235) [:3.6.0.Final] at org.hibernate.cfg.Configuration.validate(Configuration.java:1332) [:3.6.0.Final] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1835) [:3.6.0.Final] at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:902) [:3.6.0.Final] {noformat} results. If I change the type "Object" to "Serializable", the error does not occur. However, the fact that "Object" is not Serializable shouldn't matter if the field isn't being persisted. -- 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, 11 months

4
9
0 / 0

[Hibernate-JIRA] Created: (HHH-5735) Usage Path.type() in expressions throws java.lang.IllegalArgumentException

by Jaroslaw Lewandowski (JIRA)

Usage Path.type() in expressions throws java.lang.IllegalArgumentException --------------------------------------------------------------------------- Key: HHH-5735 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5735 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.6.0, 3.6.1 Reporter: Jaroslaw Lewandowski Priority: Blocker Attachments: InheritanceTest.tgz It is not possible to filter entities using Path.type() in Criteria Query API. Using type() in expressions throws an exception: Unexpected call on EntityTypeExpression#render java.lang.IllegalArgumentException: Unexpected call on EntityTypeExpression#render at org.hibernate.ejb.criteria.expression.PathTypeExpression.render( at org.hibernate.ejb.criteria.expression.PathTypeExpression.render(PathTypeExpression.java:48PathTypeExpression.java:48) ) at org.hibernate.ejb.criteria.predicate.ComparisonPredicate.render(ComparisonPredicate.java:173) at org.hibernate.ejb.criteria.QueryStructure.render(QueryStructure.java:258) at org.hibernate.ejb.criteria.CriteriaQueryImpl.render(CriteriaQueryImpl.java:340) at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:223) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:441) at foo.InheritanceTest.critQryTest(InheritanceTest.java:55) Test case is attached and it's similar to an example from JPA 2.0 specification - chapter 6.5.7 Example 2: CriteriaQuery<Employee> q = cb.createQuery(Employee.class); Root<Employee> emp = q.from(Employee.class); q.select(emp) .where(cb.notEqual(emp.type(), Exempt.class)); -- 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, 11 months

5
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5742) PersistentSet#iterator() iterates over element which had been removed from set

by Guenther Demetz (JIRA)

PersistentSet#iterator() iterates over element which had been removed from set ------------------------------------------------------------------------------ Key: HHH-5742 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5742 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0, 3.5.0-Final Environment: 3.6.0FINAL, database indipendent (attached testcase based on hsqldb) Reporter: Guenther Demetz Priority: Critical Attachments: TestIterateOverExtraLazyCollectionWithInverseOwner.jar PRECONDITONS: -the relation is declared OneToMany with inverse owner (=mappedBy attribute specified) -the relation is declared extra lazy @LazyCollection (LazyCollectionOption.EXTRA) BUG: PersistenSet.iterator().next() returns element which previously had been removed from the set myPersistenSet.remove(obj); assertFalse(myPersistenSet.iterator().next() == obj); CAUSE: PersistentSet#iterator() implementation does differ from PersistentSet#contains() and PersistentSet#size() as it doesn't call the necessary flush() if: - the set isn't initialized - the set is declared extra lazy - the set has queued Operations (hasQueuedOperations == true) to be flushed Please see attached TESTCASE for more details. This IMHO is a critical bug, as it could create serious damage to companies using hibernate: imagine a company cancels a order-position and nevertheless the canceled position is subsequently delivered or/and invoiced to the customer, because the iterator returns the removed element. Thanks for attention. -- 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, 11 months

3
7
0 / 0

[Hibernate-JIRA] Updated: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ] Gail Badner updated HHH-1268: ----------------------------- Fix Version/s: (was: 4.0.0.Beta1) 4.0.0.next > Unidirection OneToMany causes duplicate key entry violation when removing from list > ----------------------------------------------------------------------------------- > > Key: HHH-1268 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1, 3.5.6, 3.6.0 > Environment: 3.1 final > MySql 4.1.14 using MYISAM tables > Reporter: Rex Madden > Assignee: Gail Badner > Fix For: 3.2.x, 3.3.x, 3.6.5, 4.0.0.next > > Attachments: possible_solution.patch, src.zip > > > Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table) > Add 3 children to the parent. Flush. Remove the first child. Flush throws error: > Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update > at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69) > at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230) > at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143) > at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296) > at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) > at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980) > at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86) > Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2" > at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461) > at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58) > at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195) > ... 11 more > The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column. -- 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, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5313) Enabled filters, cache mode, and flush mode are not propagated to a new session via NonFlushedChanges

by Gail Badner (JIRA)

Enabled filters, cache mode, and flush mode are not propagated to a new session via NonFlushedChanges ----------------------------------------------------------------------------------------------------- Key: HHH-5313 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5313 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.x, 3.6 Enabled filters, cache mode, and flush mode are not propagated to a new session via NonFlushedChanges. -- 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, 11 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HHH-5811) flush causes update query on field of type Byte[]

by K C (JIRA)

flush causes update query on field of type Byte[] ------------------------------------------------- Key: HHH-5811 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5811 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.0 Environment: Hibernate 3.6.0.Final, Oracle 11g Reporter: K C I have a field that is mapped as follows: @Lob @Column(name = "picture") private Byte[] picture; When retrieving the entity with a regular session.load() or criteria.list(), upon session flush, an update statement is issued for the field. In an interceptor, I can see in the onFlushDirty method that the byte arrays in the currentState en previousState parameters are different objects, but with the same byte-content. All the other objects in currentState and previousState are identical. My guess is that this causes Hibernate to think the contents of the field changed? This behavior did not happen in 3.5.5-Final, and because the entity is versioned, upon each retrieval, the version field is incremented, which is highly undesirable. -- 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, 11 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HHH-5574) HQL ORDER BY descending component is not generated properly; DESC is only applied to the last component column

by Gail Badner (JIRA)

HQL ORDER BY descending component is not generated properly; DESC is only applied to the last component column --------------------------------------------------------------------------------------------------------------- Key: HHH-5574 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5574 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.6.0.CR1, 3.5.6 Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.6.x HQL ORDER BY descending component is not generated properly; DESC is only applied to the last component column. For example: HQL: select z.name, z.address from org.hibernate.test.hql.Zoo z order by z.address DESC, z.name DESC SQL: select zoo0_.name as col_0_0_, zoo0_.street as col_1_0_, zoo0_.city as col_1_1_, zoo0_.postalCode as col_1_2_, zoo0_.country as col_1_3_, zoo0_.state_prov_id as col_1_4_ from Zoo zoo0_ order by zoo0_.street, zoo0_.city, zoo0_.postalCode, zoo0_.country, zoo0_.state_prov_id DESC, zoo0_.name DESC -- 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, 11 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5531) Version update fails for inherited entity classes

by Tobias Bergman (JIRA)

Version update fails for inherited entity classes ------------------------------------------------- Key: HHH-5531 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5531 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.0.Beta4, 3.5.5 Environment: MySql 5.1.37-1 (ubuntu) Reporter: Tobias Bergman Attachments: hibernate-inheritance-bug.zip When adding an item to a collection for which the owner is fetched as READ_ONLY the version update fails if the owner class has a parent class (with a join strategy), but without parent it works. The problem is that the AbstractEntityPersister.getTableUpdateNeeded() returns with getTableHasColumns() (line 2748) when the owner is fetch as READ_ONLY. For a single table this probably works by luck. But what is the correct behavior? Should it be possible to update an READ_ONLY fetched owner's collection? -- 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, 11 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-4941) Log a message when an update to a mutable one-to-many collection of immutable entities is ignored

by Gail Badner (JIRA)

Log a message when an update to a mutable one-to-many collection of immutable entities is ignored ------------------------------------------------------------------------------------------------- Key: HHH-4941 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4941 Project: Hibernate Core Issue Type: Improvement Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.x An update to a mutable one-to-many collection is ignored when inverse="true" and the associated entity is immutable and already exists (since it cannot be updated). Should this be a debug, info, or warning message? -- 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, 11 months

2
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2011