[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Gail Badner commented on HHH-1296:
----------------------------------
The patch is really not appopriate. There should be a constraint on child ID in the link table for a one-to-many association. I you require that a child be in a collection more than once, or in multiple collections, then the collection should be mapped as many-to-many.
There is definitiely a bug in how Hibernate updates rows after a deleting an element of a collection mapped as one-to-many. This issue will be fixed by HHH-3160.
The workaround mentioned in HHH-3160 is:
"For one-to-many list associations on a foreign key, the workaround is to define the unique constraint on (owner_id, position) in the child entity table as deferred. It is assumed that the primary key in the child entity table is the child ID.
For a one-to-many list association on a join table, the workaround is to define the constraint on (child_id) in the join table as deferred. It is assumed that the primary key in the join table is (owner_id, position).
If your Dialect does not support deferred constraints, then the only workaround is to exclude the unique constraint."
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Assignee: Diego Pires Plentz
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
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
16 years, 3 months
[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Thomas Kappler (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Thomas Kappler commented on HHH-1296:
-------------------------------------
I'm wondering, too.
Gail, a SortedSet is not always the appropriate collection type here. In my app, users can manually reorder a list, and exactly this ordering must be persisted. That's only possible with an index column, isn't it?
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Assignee: Diego Pires Plentz
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
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
16 years, 3 months
[Hibernate-JIRA] Commented: (HHH-1296) Non lazy loaded List updates done in wrong order, cause exception
by Felix Engelhardt (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296?page=c... ]
Felix Engelhardt commented on HHH-1296:
---------------------------------------
I've had this exact problem too with Hibernate 3.2.6 and Annotations 3.3.0. After applying the patch and rebuilding Annotations it seems to be fixed. I wonder how an issue like this could last for so long. Or am I missing something here?
> Non lazy loaded List updates done in wrong order, cause exception
> -----------------------------------------------------------------
>
> Key: HHH-1296
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1296
> Project: Hibernate3
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5 - any database (checked postgres 7/8, mysql 4 & 5, db2 v8)
> NOT using lazy loading - the tx's are wrapped by session beans, so lazy loading is not allowed.
> Reporter: David Birch
> Assignee: Diego Pires Plentz
> Priority: Critical
> Attachments: listupdate_patch.txt, listupdate_patch.txt, listupdate_testcase.zip
>
>
> The logic behind list updates is not quite right, nor was it in v2 (only now i have a DBA who won't let up...)
> The scenario is:
> a bean with list property, and the list has a number of items in it (say 4, index 0-3), an item is then removed (say item at index 2), and the bean is requested to be saved.
> From what i can see in the SQL traces, the same statements are issues whe lazy loading is on or off, they are:
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: delete from TGE_CLIENT_POLICY where CLIENT_ID=? and POSITION=?
> [18/12/05 19:48:50:766 EST] 00000036 SystemOut O Hibernate: update TGE_CLIENT_POLICY set POLICY_NK=? where CLIENT_ID=? and POSITION=?
> So, i can only assume (as when this fails, the row with index 1 above the removed row is nuked!), hibernate removes the item at index 3, and then copies the value of the item at index 3 onto the row for item at index 2. Fair enough but...
> When i have lazy loading off, i get DB exceptions like
> Duplicate key or integrity constraint violation message from server: "Duplicate entry '1-999999' for key 1"
> so, there is some nasty in there, which is not updating the correct row - this has happened since 2.1.8 that i know of :(
> i will try & look @ the source, but won't get a chance until after xmas...
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HBX-1046) Reverse Engineering: Eclipse Plug-in: suppress connection information from generated hibernate.cfg.xml
by Martin Hache (JIRA)
Reverse Engineering: Eclipse Plug-in: suppress connection information from generated hibernate.cfg.xml
------------------------------------------------------------------------------------------------------
Key: HBX-1046
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1046
Project: Hibernate Tools
Issue Type: Improvement
Components: reverse-engineer
Affects Versions: 3.2.cr1
Environment: Hibernate 3.2.5ga
Oracle 10j
Eclipse 3.3.1.1
Reporter: Martin Hache
We're using the latest Hibernate Tools Plugin for Eclipse (3.2.0GA.) and we're reverse engineering our hibernate.cfg.xml file, unfortunately, the generated file (used at runtime by the application) contains the following settings that we need to suppress:
<property name="hibernate.connection.driver_class">oracle.jdbc.driver.OracleDriver</property>
<property name="hibernate.connection.password">shhhhhh</property>
<property name="hibernate.connection.url">jdbc:oracle:thin:@server.domain.com:1542:SID</property>
<property name="hibernate.connection.username">my_schema</property>
<property name="hibernate.default_schema">my_schema</property>
We reverse-engineer out of our DEV environment so we need to put these in the hibernate.cfg.xml file used during the reverse-engineering process but we don't want them in the generated (runtime) file because we use a Data Source in our J2EE container which points to different databases and because these connection information represents a security risk.
The connection information is undesirable but at least the Data Source takes precedence at runtime; however, the hibernate.default_schema is a problem because that too changes in different environments within the enterprise. We're presently using a process in Ant to remove the value from the generated hibernate.cfg.xm but this it is a ticking time-bomb waiting to go off during some future maintenance phase of the application.
Would it be possible to add some sort of argument to allow us to decide if these values should be propagated to the generated file or not? Or to allow the connection and schema info to be externalized?
My team has been unable to find documentation on how to do this and I have received no responses to posts in the forum so we're working under the assumption that it's not possible.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (ANN-650) Explicitly disallow @Version on @Embedded and throw meaningful Exception
by Chris Bredesen (JIRA)
Explicitly disallow @Version on @Embedded and throw meaningful Exception
------------------------------------------------------------------------
Key: ANN-650
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-650
Project: Hibernate Annotations
Issue Type: Improvement
Components: binder
Affects Versions: 3.3.0.ga
Environment: Hibernate Annotations 3.3.0.GA
Hibernate 3.2.2
Hibernate EntityManager 3.3.1.GA
Reporter: Chris Bredesen
Priority: Minor
The above situation should be explicitly checked for and a meaningful exception thrown. Currently, this configuration blows up with the following trace:
java.lang.ArrayIndexOutOfBoundsException: -66
at org.hibernate.persister.entity.AbstractEntityPersister.checkVersion(AbstractEntityPersister.java:1855)
at org.hibernate.persister.entity.AbstractEntityPersister.generateUpdateString(AbstractEntityPersister.java:1811)
at org.hibernate.persister.entity.AbstractEntityPersister.generateUpdateString(AbstractEntityPersister.java:1777)
at org.hibernate.persister.entity.AbstractEntityPersister.postConstruct(AbstractEntityPersister.java:2930)
at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:409)
at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:730)
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HHH-3154) Criteria API use - duplicate SQL alias might be generated for subquery
by Denis Mukhin (JIRA)
Criteria API use - duplicate SQL alias might be generated for subquery
----------------------------------------------------------------------
Key: HHH-3154
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3154
Project: Hibernate3
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.6
Reporter: Denis Mukhin
>From org/hibernate/criterion/SubqueryExpression.java - Hibernate 3.2.6 sources:
-------------------------------
private void createAndSetInnerQuery(CriteriaQuery criteriaQuery, final SessionFactoryImplementor factory) {
...
//with two-deep subqueries, the same alias would get generated for
//both using the old method (criteriaQuery.generateSQLAlias()), so
//that is now used as a fallback if the main criteria alias isn't set
String alias;
if ( this.criteriaImpl.getAlias() == null ) {
alias = criteriaQuery.generateSQLAlias();
}
else {
alias = this.criteriaImpl.getAlias() + "_";
}
...
}
-------------------------------
This implementation means that if DetachedCriteria (passed to SubqueryExpression constructor) created without alias explicitely specified, generated SQL alias might be duplicate of what is generated for outer query because:
1. Class org.hibernate.impl.CriteriaImpl has 2 arg constructor (entity/class name and session implementor). It creates object with alias set to "this". This constructor is used from DetachedCriteria.forEntityName(String) or DetachedCriteria.forName(Class), thus DetachedCriteria is created with not-null default alias.
2. As comment in original code says generateSQLAlias() also may return duplicate names.
The simplest solution I see is to always generate there SQL alias based, for instance, on SubqueryExpression class name and increasing counter stored in static field.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (HHH-3114) Subqueries in Criteria-API use wrong table alias
by Gerald Glocker (JIRA)
Subqueries in Criteria-API use wrong table alias
------------------------------------------------
Key: HHH-3114
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3114
Project: Hibernate3
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.6
Reporter: Gerald Glocker
Priority: Blocker
Subqueries (exists, notExists, and probably others) are formulated using table alias "this_" but the outer query also uses the same table alias.
This is a serious mistake for subqueries working on the same table or for subqueries on tables with the same column names.
Example:
DetachedCriteria c = DetachedCriteria.forClass(Person.class, "a");
c.add(Restrictions.eq("lastname", "Smith"));
DetachedCriteria sub = DetachedCriteria.forClass(Person.class);
sub.setProjection(Projections.property("id"));
sub.add(Restrictions.eqProperty("lastname", "a.lastname"));
sub.add(Restrictions.gtProperty("dob", "a.dob"));
c.add(Subqueries.exists(sub));
List persons = ht.findByCriteria(c);
Produces SQL:
select this_.id as id4_0_,
this_.firstname as firstname4_0_,
this_.lastname as lastname4_0_,
this_.dob as dob4_0_
from Person this_
where this_.lastname = ?
and exists (select this_.id as y0_
from Person this_
where this_.lastname = this_.lastname
and this_.dob > this_.dob)
The error can cleary be seen on the where-condition "this_.dob > this_.dob".
Please try to fix this problem soon. A running test could be provided.
--
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
16 years, 3 months
[Hibernate-JIRA] Created: (ANN-673) Guaranty column order in genereted schema
by Ivo Danihelka (JIRA)
Guaranty column order in genereted schema
-----------------------------------------
Key: ANN-673
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-673
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Affects Versions: 3.2.1, 3.3.1
Environment: Hibernate 3.2.1 and SVN, PostgreSQL 8.1
Reporter: Ivo Danihelka
Priority: Minor
Attachments: fk-order.path
Problem:
- AnnotationConfiguration does not define stable ordering for foreign key columns. They then could appear in generated SQL schema in any order. For example, sometimes table foreign key column person_id is before another foreign key column dog_id and sometimes it is behind it.
Tool hbm2ddl could be used to see the generated schema. The order of foreign key columns in one table changes
when unrelated change is made inside mapping of a different table.
Proposed Solution:
- Don't base the ordering of foreign keys on hashCode. Base it on tableName+propertyName.
A patch against hibernate 3.2.1 is attached (it also backportes #ANN-551 into 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
16 years, 3 months