February 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2608) allow delete-orphan cascade style in one-to-one mapping

by Joe Kelly (JIRA)

allow delete-orphan cascade style in one-to-one mapping ------------------------------------------------------- Key: HHH-2608 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2608 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.4 Environment: 3.2.4, DB2 v8 Reporter: Joe Kelly Please allow the cascade-style "delete-orphan" for one-to-one relationships. When I try to use that cascade style, I get the exception "org.hibernate.MappingException: single-valued associations do not support orphan delete". I realize that the reference manual says "Note that single valued associations (many-to-one and one-to-one associations) do not support orphan delete." But why? I can think of many cases where you WOULD want parent-child semantics in a one-to-one relationship. For example, I have encountered some legacy databases where an entity has all of its fields stored in one table EXCEPT for an optional large field (e.g. a blob field) that is stored in another table, presumably for some performance or storage optimization reason. In this case the two tables are joined with a one-to-one relationship, using a shared primary key. Here are some hypothetical tables, classes and mappings that illustrate this example: company ( company_id (PK) name ) company_extra ( company_extra_id (PK), (FK referencing company.company_id) some_extra_info ) class Company { int companyId; String name; CompanyExtra companyExtra; } class CompanyExtra { int companyExtraId; String someExtraInfo; Company company; } <class name="Company" table="company"> <id name="companyId" column="company_id"> <generator class="sequence"> <param name="sequence">COMPANY_SEQ</param> </generator> </id> <property name="name" column="name" /> <one-to-one name="companyExtra" class="CompanyExtra" cascade="all, delete-orphan" /> </class> <class name="CompanyExtra" table="company_extra"> <id name="companyExtraId" column="company_extra_id" unsaved-value="null"> <generator class="foreign"> <param name="property">company</param> </generator> </id> <property name="someExtraInfo" column="some_extra_info" /> <one-to-one name="company" class="Company" constrained="true" /> </class> For the purposes of this example, CompanyExtra is a child of Company and belongs to one and only one instance of Company. It cannot be shared between Company instances and it cannot be an orphan (i.e. it cannot exist without a parent Company). Also, CompanyExtra is optional so you can have a Company without any associated CompanyExtra during Company's lifecycle. To me, it seems natural and logical that if you set Company.companyExtra to null, and save Company, Hibernate should automatically delete the associated record in the company_extra table if the delete-orphan cascade style is configured (which, of course, it not currently allowed). This is what I want to do when editing an existing Company instance: aCompany = session.load(...); aCompany.setCompanyExtra(null); aCompany.setName("some new name"); session.save(aCompany); // automatically deletes company_extra record For now, I think the workaround is to explicitly delete the CompanyExtra instance in Java code but that just doesn't seem natural to me and it isn't transparent. I do NOT want to do this: aCompany = session.load(...); companyExtra = aCompany.getCompanyExtra(); // ***extra, unnatural method call aCompany.setCompanyExtra(null); aCompany.setName("some new name"); session.save(aCompany); session.delete(companyExtra); // ***another extra, unnatural method call -- 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

15 years, 9 months

17
20
0 / 0

[Hibernate-JIRA] Created: (ANN-573) Many-to-many with Attributes (Attribute-class with two @ManyToOne mappings as @Id) not possible

by Christian Köberl (JIRA)

Many-to-many with Attributes (Attribute-class with two @ManyToOne mappings as @Id) not possible ----------------------------------------------------------------------------------------------- Key: ANN-573 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-573 Project: Hibernate Annotations Type: Bug Components: binder Versions: 3.2.1 Environment: Hibernate+Annotations 3.2.1-ga, HSQLDB 1.8.0.7 Reporter: Christian Köberl Attachments: manytomanybug.zip Im trying to map the following relation: Order 1-n OrderLine m-1 Product where the OrderLine contains an amount of the ordered product. The problem seems to be multiple @Id in combination with @ManyToOne: @Entity @Table(name = "order_line") // @IdClass(OrderLinePK.class) public class OrderLine implements Serializable { @Id @ManyToOne(targetEntity = Order.class) @JoinColumn(name = "order_id", nullable = false) private Order order; @Id @ManyToOne(targetEntity = Product.class) @JoinColumn(name = "product_id", nullable = false) ... } Hibernate maps the OrderLine class in the following way: DEBUG SchemaUpdate:149 - create table order_line (product varbinary(255) not null, order varbinary(255) not null, amount integer, primary key (order)) (maybe this relates to http://opensource.atlassian.com/projects/hibernate/browse/ANN-435) When I add an IdClass to the OrderLine, I get the following exception: Initial SessionFactory creation failed.org.hibernate.AnnotationException: mappedBy reference an unknown target entity property: model.OrderLine.order in model.Order.lineItems The example is attached as a runnable Maven2-Project, just run mvn test. The test dao.OrderDaoAnnotationTest fails. In the project I also tried to map the same classes with hbm-Files and this works (dao.OrderDaoHbmTest). -- 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

15 years, 9 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2439) delay IDENTITY insertions in the case of FlushMode.MANUAL/NEVER

by Steve Ebersole (JIRA)

delay IDENTITY insertions in the case of FlushMode.MANUAL/NEVER --------------------------------------------------------------- Key: HHH-2439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2439 Project: Hibernate3 Type: Improvement Components: core Reporter: Steve Ebersole Assigned to: Steve Ebersole Fix For: 3.2.3 Much like we do now in 3.2 for out of transaction operations, we should delay performing insertions for post-insert generators with FlushMode.isManualFlushMode -- 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

15 years, 9 months

5
20
0 / 0

[Hibernate-JIRA] Created: (HHH-2309) fetch only the lazy property needed

by German de la Cruz (JIRA)

fetch only the lazy property needed ------------------------------------ Key: HHH-2309 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2309 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.1 Reporter: German de la Cruz The method AbstractEntityPersister.initializeLazyProperty(..) load all lazy properties when it's called. It would be great if could only load the requested property. I think the only change we need is in AbstractEntityPersister.initializeLazyPropertiesFromDatastore(...) and AbstractEntityPersister.initializeLazyPropertiesFromCache(...). We must change them in a way that only the referenced property is loaded. After that, we must change AbstractFieldInterceptor.intercept(..) to update in a better way the unitializedFields collection (I mean, removing the actual property only instead of null it). Besides. Why in line 777 to 780 a query is executed? I think it isn't necessary. Thanks. -- 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

15 years, 9 months

5
12
0 / 0

[Hibernate-JIRA] Created: (HHH-3077) Move references to LRUMap and ReferenceMap

by Stephen Kestle (JIRA)

Move references to LRUMap and ReferenceMap ------------------------------------------ Key: HHH-3077 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3077 Project: Hibernate3 Issue Type: Sub-task Reporter: Stephen Kestle -- 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

15 years, 9 months

2
3
0 / 0

[Hibernate-JIRA] Erstellt: (HHH-2224) executeUpdate causes coarse cache invalidation

by Stefan Fleiter (JIRA)

executeUpdate causes coarse cache invalidation ---------------------------------------------- Key: HHH-2224 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2224 Project: Hibernate3 Type: Improvement Versions: 3.2.0.ga Environment: Hibernate 3.2.0.ga, Oracle 9.2 Reporter: Stefan Fleiter Attachments: bulk_testcase.zip I am developing an application and want to mix bulk-updates with normal hibernate operations. The bulk updates work fine, but invalidate the whole region and I've found no possibility to prevent this. There would be 3 options to improve: - Invalidate only the modified objects if the ids where given as Query-parameters. - Let me deactivate the invalidation so I can invalidate the affected objects myself. - Transform the DML to a select to gather the objects to invalidate before executing the DML The reference documentation does not mention caching at all: http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#batch-direct The best documentation I've found is: http://blog.hibernate.org/cgi-bin/blosxom.cgi/2005/07/19#dml-basic Maybe this could be added to the reference documentation... I already posted this at the forum http://forum.hibernate.org/viewtopic.php?t=966775 but did not get a single answer. I've attached a testcase for this. -- 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

15 years, 9 months

10
19
0 / 0

[Hibernate-JIRA] Created: (HHH-2470) Use of session.createSQLQuery causes memory leak

by Bjørn Bjerkeli (JIRA)

Use of session.createSQLQuery causes memory leak ------------------------------------------------- Key: HHH-2470 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.1.3 Environment: Win XP, Oracle 10g, Java 1.4.2 Reporter: Bjørn Bjerkeli Attachments: TestCase.zip NativeSQLQuerySpecification fails to properly implement equals and hashcode caused by lacking implementation of hashCode and equals in all SQLQueryReturn implementations and SQLQueryScalarReturn which are members of NativeSQLQuerySpecification. I can see that NativeSQLQuerySpecification has been changed in 3.2, but the problem is still there. NativeSQLQuerySpecification instances are used as keys for retrieving and caching NativeSQLQueryPlan instances. This causes the caching-mechanism to be pretty useless when Queries created by session.createSQLQuery because new entries will be added all the time in the QueryPlanCache and the SoftLimitMRUCache member. So far so good, the more serious problem that is caused by this is stems from the implementation of SoftLimitMRUCache which again uses LRUMap in commons-collection. The put - method of the cache is not treadsafe, and that causes the following fragment in LRUMap to allow the map to grow beyond its maximumSize. That is bacause the containsKey method will return an incorrect result when concurrently updating the map. public Object put( Object key, Object value ) { int mapSize = size(); Object retval = null; if ( mapSize >= maximumSize ) { // don't retire LRU if you are just // updating an existing key if (!containsKey(key)) { // lets retire the least recently used item in the cache removeLRU(); } } retval = super.put(key,value); return retval; } I have included a test-case that demonstrates: 1) Wrong implementation of equals and hashCode in NativeSQLQuerySpecification 2) Concurrent use of LRUMap causes the map to grow beyound it's max limit 3) Concurrent execution of session.createSQLQuery causes memory leak due to 1) and 2) I would be more than happy to contribute to get this fixed. Just let me know. -- 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

15 years, 9 months

14
23
0 / 0

[Hibernate-JIRA] Created: (HHH-3221) Cascading performance problems when session contains many entities

by Yves Galante (JIRA)

Cascading performance problems when session contains many entities ------------------------------------------------------------------ Key: HHH-3221 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3221 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5 Reporter: Yves Galante Attachments: patchCascading.patch, SaveTest.zip When session contains many entities, performence of cascading become very slow. For each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection. This patch optimize cascading operation by caching relation parent-child on a map. eventSource.getPersistenceContext().addChildParent(child, parent); action.cascade(eventSource, child, entityName, anything, isCascadeDeleteEnabled); eventSource.getPersistenceContext().removeChildParent(child); The test case save and flush 10 * 551 objects. Before patch save object with cascading is more slow when session size grows. After patch time of save stay same at each loop. Output of the test case before the patch : Save took 449 ms Save took 669 ms Save took 1042 ms Save took 1464 ms Save took 2481 ms Save took 2741 ms Save took 3807 ms Save took 4344 ms Save took 4975 ms Save took 5251 ms Total took 30906 ms Output after the patch Save took 445 ms Save took 144 ms Save took 164 ms Save took 108 ms Save took 93 ms Save took 93 ms Save took 93 ms Save took 94 ms Save took 91 ms Save took 89 ms Total took 4905 ms -- 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

15 years, 9 months

4
10
0 / 0

[Hibernate-JIRA] Created: (ANN-793) @ManyToOne - @OneToMany doesn't work with @Inheritance(strategy= InheritanceType.JOINED)

by Tomaz Cerar (JIRA)

@ManyToOne - @OneToMany doesn't work with @Inheritance(strategy= InheritanceType.JOINED) ---------------------------------------------------------------------------------------- Key: ANN-793 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-793 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.4.0.GA Environment: Hibernate Core 3.3.1.GA Hibernate Annotations 3.4.0 GA Hibernate EntityManager 3.4.0 GA Jboss 4.3 EAP, DB2 9.5 Reporter: Tomaz Cerar I am trying to create bidirectional association between two entities in which one can be Inherited and it fails with table not found: 11:37:39,229 ERROR [AssertionFailure] [] an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.AssertionFailure: Table CRM.CRM_AKTIVNOST_DOGODKI not found at org.hibernate.persister.entity.JoinedSubclassEntityPersister.getTableId(JoinedSubclassEntityPersister.java:480) at org.hibernate.persister.entity.JoinedSubclassEntityPersister.<init>(JoinedSubclassEntityPersister.java:259) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:87) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:261) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1327) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:669) at org.hibernate.ejb.HibernatePersistence.createContainerEntityManagerFactory(HibernatePersistence.java:132) at org.jboss.ejb3.entity.PersistenceUnitDeployment.start(PersistenceUnitDeployment.java:246) The code looks like this: @Entity @Table(name = "CRM_AKTIVNOST") public class Aktivnost implements Serializable { private List<Dogodek> dogodki; .... .... @OneToMany(fetch = FetchType.LAZY, cascade = CascadeType.ALL,mappedBy = "aktivnost") public List<Dogodek> getDogodki() { return dogodki; } public void setDogodki(List<Dogodek> dogodki) { this.dogodki = dogodki; } ... ... } @Entity @Table(name = "CRM_DOGODEK") @Inheritance(strategy= InheritanceType.JOINED) public class Dogodek implements Serializable { ... ... private Aktivnost aktivnost; .... .... @ManyToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) @JoinTable(name = "CRM_AKTIVNOST_DOGODKI", joinColumns = {@JoinColumn(name = "DOGODEK_ID")}, inverseJoinColumns = {@JoinColumn(name = "AKTIVNOST_ID")}) public Aktivnost getAktivnost() { return aktivnost; } public void setAktivnost(Aktivnost aktivnost) { this.aktivnost = aktivnost; } ... } -- 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

15 years, 9 months

9
12
0 / 0

[Hibernate-JIRA] Created: (HHH-3694) ResultTransformer not used when scroll() is used on a named SQLQuery

by Oscar Pearce (JIRA)

ResultTransformer not used when scroll() is used on a named SQLQuery -------------------------------------------------------------------- Key: HHH-3694 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3694 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: Hibernate Core 3.3.1, PostgreSQL 8.1, HSQLDB 1.8 Reporter: Oscar Pearce Priority: Minor Attachments: sqlqueryrestrans.zip If a ResultTransformer is set on a named SQLQuery, and then scroll() is used on the query, the ResultTransformer is never used. The unit test in the attached Maven project shows this. The fix seems simple - a one-line change in org.hibernate.loader.custom.CustomLoader#getHolderInstantiator(ResultTransformer resultTransformer, String[] queryReturnAliases). The sense of the test of resultTransformer against null should be reversed. -- 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

15 years, 9 months

5
16
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 February 2009