January 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HBX-1196) Allow use of orphanRemoval jpa2 property in collection annotations for cascade

by Thomas Guerin (JIRA)

Allow use of orphanRemoval jpa2 property in collection annotations for cascade ------------------------------------------------------------------------------ Key: HBX-1196 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1196 Project: Hibernate Tools Issue Type: Improvement Components: reverse-engineer Affects Versions: 3.2.4.GA Environment: Hibernate 3.6.8.Final, Hsqldb Reporter: Thomas Guerin Priority: Minor Attachments: orphanRemoval.java With jpa2 it would be better to use orphanRemoval property instead of hibernate specific annotation. An easy way to fix it is to allow DELETE or ORPHAN_REMOVAL value in cascade values and then append orphanRemoval=true in the generated annotation right after the cascadeType property in org.hibernate.tool.hbm2x.pojo.EntityPOJOClass.generateCollectionAnnotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6994) EntityEntry should not be Serializable

by Steve Ebersole (JIRA)

EntityEntry should not be Serializable -------------------------------------- Key: HHH-6994 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6994 Project: Hibernate ORM Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.0 The main issue is the inability to call back into the PersistentContext to which is belongs -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6725) Bidirectional @OneToOne(optional=true) with a foreign ID generator should force optional=false

by Gail Badner (JIRA)

Bidirectional @OneToOne(optional=true) with a foreign ID generator should force optional=false ---------------------------------------------------------------------------------------------- Key: HHH-6725 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6725 Project: Hibernate Core Issue Type: Improvement Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next When a foreign ID generator is used with @OneToOne(optional=true), Hibernate should: - force optional=false - log a warning The default for @OneToOne is optional=true This should be done when a foreign ID generator is used - with @OneToOne @PrimaryKeyJoinColumn - with @OneToOne(mappedBy="...") Currently, Hibernate allows the one-to-one association to be optional, but if the association is set to null, IdentifierGenerationException is thrown. I don't think it's possible to check for a ForeignGenerator until the SessionFactory or persister is being built with a Configuration object. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-6993) Cacheable attribute in jpa mapping file is ignored

by Tien Tran (JIRA)

Cacheable attribute in jpa mapping file is ignored -------------------------------------------------- Key: HHH-6993 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6993 Project: Hibernate ORM Issue Type: Bug Affects Versions: 3.6.9 Reporter: Tien Tran While "access" and "metadata-complete" are recognised (org.hibernate.cfg.annotations.reflection.XMLContext.addClass() - line 152, 156), "cacheable" property as part of JPA 2.0 is ignored. Should it be read and override the annotated value if any? {code}<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd" version="2.0"> <entity class="path.to.Entity" access="FIELD" metadata-complete="false" cacheable="true" /> </entity-mappings> {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (METAGEN-76) SingularAttribute generated for hashCode method in @Embeddable

by Hrotkó Gábor (JIRA)

SingularAttribute generated for hashCode method in @Embeddable -------------------------------------------------------------- Key: METAGEN-76 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-76 Project: Hibernate Metamodel Generator Issue Type: Bug Components: processor Affects Versions: 1.1.1.Final Environment: hibernate-jpamodelgen 1.1.1.Final, postgresql 8 Reporter: Hrotkó Gábor Assignee: Hardy Ferentschik I got a class composite id class for a table with @Embeddable. It has two properties, and the equals and the hashCode methods. When hibernate-jpamodelgen 1.1.1.Final generates the metaclasses, I got a SingularAttribute with the name "hashCode" generated. But hashCode is not a property in the entity. entity: /** by hbm2java */ @Embeddable public class MyTableId implements java.io.Serializable { private String id; private Integer memberId; public MyTableId() { } public MyTableId(String id, Integer memberId) { this.id = id; this.memberId = memberId; } @Column(name="id") public String getId() { return this.id; } public void setId(String id) { this.id = id; } @Column(name="member_id") public Integer getMemberId() { return this.memberId; } public void setMemberId(Integer memberId) { this.memberId = memberId; } public boolean equals(Object other) { if ( (this == other ) ) return true; if ( (other == null ) ) return false; if ( !(other instanceof MyTableId) ) return false; MyTableId castOther = ( MyTableId ) other; return ( (this.getId()==castOther.getId()) || ( this.getId()!=null && castOther.getId()!=null && this.getId().equals(castOther.getId()) ) ) && ( (this.getMemberId()==castOther.getMemberId()) || ( this.getMemberId()!=null && castOther.getMemberId()!=null && this.getMemberId().equals(castOther.get MemberId()) ) ); } public int hashCode() { int result = 17; result = 37 * result + ( getId() == null ? 0 : this.getId().hashCode() ); result = 37 * result + ( getMemberId() == null ? 0 : this.getMemberId().hashCode() ); return result; } } metaclass: @StaticMetamodel(MyTableId.class) public abstract class MyTableId_ { public static volatile SingularAttribute<MyTableId, String> id; public static volatile SingularAttribute<MyTableId, Integer> hashCode; public static volatile SingularAttribute<MyTableId, Integer> memberId; } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

3
7
0 / 0

[Hibernate-JIRA] Created: (METAGEN-79) The _@Generated_ annotation should be added by default

by Hardy Ferentschik (JIRA)

The _@Generated_ annotation should be added by default ------------------------------------------------------ Key: METAGEN-79 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-79 Project: Hibernate Metamodel Generator Issue Type: Task Components: processor Affects Versions: 1.1.1.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.2.next The _@Generated_ annotation should be added by default. The option _addGeneratedAnnotation_ should be changed to _skipGeneratedAnnotation_. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-304) Subselect fetching with setMaxResults()

by umanath kandhallu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-304?page=co... ] umanath kandhallu commented on HHH-304: --------------------------------------- i used following as a work around @Fetch(FetchMode.JOIN) @BatchSize(size=200) so the generated query was like select * from child where parentid in (?,?,?...) instead of select * from child where parentid in (criteria query which used to select parent) > Subselect fetching with setMaxResults() > --------------------------------------- > > Key: HHH-304 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-304 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.0 final > Reporter: Gavin King > Assignee: Gavin King > > Any limit that gets applied to a query should also get applied to the subselect of any subsequent collection fetches. > Also, we need to make sure that a newly inserted collection that shows up in the subselect fetch resultset gets ignored by Loader. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1525) multiple cascades to the same transient instance within a single object graph

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1525?page=c... ] Gail Badner resolved HHH-1525. ------------------------------ Resolution: Duplicate > multiple cascades to the same transient instance within a single object graph > ----------------------------------------------------------------------------- > > Key: HHH-1525 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1525 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > > Consider an object graph being saved that contains the same transient instance multiple times (at diffierent levels in the graph) where some of the associations define cascading and some do not and that the associations without cascading are further defined as not-null. Based on the order in which the associations are cascaded there is a potential for that transient instance to cause an "unsaved transient instance" exception if the non-cascaded and not-null association is cascaded to first, even though a subsequent cascaced would in fact cause the instance to become managed. > Typically this is easy enough to work around by simply reordering the associations in the mapping so that the cascaded association is before the non-cascaded one. However, this is not always possible (the case of inheritence hierarchies comes to mind, where the superclass associations are always cascaded to first). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4550) query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets!

by Guenther Demetz (JIRA)

query cache: Attention with configuring Update Timestamps Cache region: expired entries cause wrong result sets! ---------------------------------------------------------------------------------------------------------------- Key: HHH-4550 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4550 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.2 Environment: 3.3.2 GA Reporter: Guenther Demetz Priority: Trivial Attachments: TestCaseQuryCache.jar When using hibernate's query cache (hibernate.cache.use_query_cache), then it's of fundamental importance to configure the Update Timestamps cache region in a way that his entries survive longer than the cached result sets in the Query cache region. Otherwise queries could return wrong (obsolete) result sets (See attached testcase). This is because the current UpdateTimestampsCache#isUpToDate implementation considers a result-set also as up-to-date, if there are no update-timestamps cached for the interested spaces (tables) at all. It if therefore important to notice that: 1- The Update-Timestamps-Cache-Region elements max-size should be configured higher than the number of tables you have on the db-schema, in manner that he can remember/hold the last update-timestamp for each table. 2- If you use any other eviction policy in the Update-Timestamps-Cache-Region, then you must assure that cached result sets in the Query-cache-region are evicted before relevant update-timestamps are going to be evicted. This fact should be clearly documented somewhere. Thanks G.D. -- 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

14 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3892) Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[]

by Gail Badner (JIRA)

Improve support for mapping SQL LONGVARCHAR and CLOB to Java String, SQL LONGVARBINARY and BLOB to Java byte[] --------------------------------------------------------------------------------------------------------------- Key: HHH-3892 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3892 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.2.x, 3.3.x, 3.5 Property types will be provided to enable an application to process data for a java.sql.Types.LONGVARCHAR or java.sql.Types.CLOB column as a Java String. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java string. text - property type to map java.sql.Types.LONGVARCHAR column data as a Java String (via org.hibernate.type.TextType); (NOTE: currently, org.hibernate.type.TextType incorrectly maps "text" to java.sql.Types.CLOB; this will be fixed by this issue and updated in database dialects) materialized_clob - property type to map java.sql.Types.CLOB column data as a Java String (via org.hibernate.type.MaterializedClobType); In addition, new property types will be provided to enable an application to process data for a java.sql.Types.LONGVARBINARY or java.sql.Types.BLOB column as Java byte[]. Hibernate will internally process the data as a streams. On a read, stream data will immediately be materialized into a Java byte[]. image - property type to map java.sql.Types.LONGVARBINARY column data as byte[] (via org.hibernate.type.ImageType); materialized_blob - property type to map java.sql.Types.BLOB column data as byte[] (via org.hibernate.type.MaterializedBlobType); -- 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

14 years, 2 months

3
6
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 January 2012