May 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3910) Add support for custom dirty checking during flush

by Ovidio Mallo (JIRA)

Add support for custom dirty checking during flush -------------------------------------------------- Key: HHH-3910 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3910 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Reporter: Ovidio Mallo Currently, Hibernate supports a special dirty checking on instrumented entities in order to improve the flush performance. IMO, this optimization can often be rather significant. However, the drawback is that you have to use bytecode instrumentation in order to take advantage of this performance improvement which might not be an option in some projects. Therefore, I wanted to propose to extend the current dirty checking during flush in such a way that the dirtyness information can also be directly provided by clients. Thereby, I could think of two possible approaches to do this: 1. Introduce an interface which client entities might implement in case they have some notion of dirtyness. The interface could look something like: public interface DirtyAwareEntity { boolean getMightBeDirty(); void setMightBeDirty(boolean mightBeDirty); } Using such an interface, Hibernate could easily check whether an entity might be dirty during flush and it could also reset the dirty flag after flush just as is currently done for instrumented classes. So this approach would probably be rather easy to implement and very convenient for clients since they would only have to implement that interface on the appropriate entities and set the dirty flag when the entity is actually modified. 2. Add some hooks on event listeners and/or on the Interceptor for querying whether an entity is dirty and for resetting the dirty flag. E.g. one could add the following hook method to the DefaultFlushEntityEventListener class: protected boolean requiresDirtyCheck(FlushEntityEvent event); By default, this method would call EntityEntry#requiresDirtyCheck(Object entity) as is done right now. Resetting the dirty flag could maybe be done in Interceptor#postFlush() or some dedicated method could be provided. BTW, I know that currently there already is the Interceptor#findDirty() method which already allows for some custom dirty checking but the problem from a performance point of view is that this method requires the entity's property values as parameter which are retrieved in DefaultFlushEntityEventListener#getValues() which is the most expensive method during flush. This drawback of the findDirty() method has often been noticed in comments on the news groups. I personally think it would be nice if something could be done to improve the performance of flushing in Hibernate since from what I read on the news groups and the like, flushing still seems to often lead to performance problems in practice, especially in larger projects where it is often not easy to avoid flushes or to keep the numer of entities in the session cache small. In fact, we are having quite some trouble with that in our project and having some custom dirty checking like the one I'm proposing here would greatly help in our project and in other projects as well, I guess. -- 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, 10 months

3
25
0 / 0

[Hibernate-JIRA] Created: (HHH-5024) MetadataContext#registerAttribute does not recognize inherited fields

by Adrian Hummel (JIRA)

MetadataContext#registerAttribute does not recognize inherited fields --------------------------------------------------------------------- Key: HHH-5024 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5024 Project: Hibernate Core Issue Type: Bug Components: entity-manager, metamodel Affects Versions: 3.5.0-CR-2 Environment: Hibernate 3.5.0-CR-2, JPA Modelgen 1.0.0-CR-1 Reporter: Adrian Hummel Priority: Critical Attachments: bugreport.zip The embeddable class {{CustomerId}} (see attached ZIP) inherits from the base class {{AbstractIdentity}} (annotated with {{@MappedSuperclass}}). The metamodel classes for these two classes are correctly generated: {code:title=AbstractIdentity_.java|borderStyle=solid} import javax.persistence.metamodel.SingularAttribute; import javax.persistence.metamodel.StaticMetamodel; @StaticMetamodel(AbstractIdentity.class) public abstract class AbstractIdentity_ { public static volatile SingularAttribute<AbstractIdentity, String> id; } {code} and {code:title=CustomerId_.java|borderStyle=solid} import javax.persistence.metamodel.StaticMetamodel; @StaticMetamodel(CustomerId.class) public abstract class CustomerId_ extends AbstractIdentity_ { } {code} When building the entity manager factory, {{MetadataContext#registerAttribute}} (line 378) tries to resolve the field {{CustomerId_.id}} using {{Class#getDeclaredField}}. This results in a {{NoSuchFieldException}} because the field is declared in the super class {{AbstractIdentity_}}. Proposed solution: Since all field declarations in the metamodel are public, the {{Class#getField}} method should be used instead. -- 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, 10 months

12
41
0 / 0

[Hibernate-JIRA] Created: (HHH-2879) consolidate approach for id and natural-id loading

by Steve Ebersole (JIRA)

consolidate approach for id and natural-id loading -------------------------------------------------- Key: HHH-2879 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2879 Project: Hibernate3 Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Currently, natural-id "loading' is only available through some incomplete criteria query hackery. Would like to expose a proper API for performing natural-id loading. In addition, would like this to be consolidated with the effort to cleanup the Session API and so have a unified way to load entities: Session.getLoader( MyEntity.class ).get( id ) Session.getNaturalIdLoader( MyEntity.class ).get( naturalId ) *DISCLAIMER : do not like the term 'loader' here because of ambiguity* -- 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, 10 months

2
16
0 / 0

[Hibernate-JIRA] Created: (HHH-3853) one-to-one mapping doesn support Primary Key Association

by Amar Singh (JIRA)

one-to-one mapping doesn support Primary Key Association -------------------------------------------------------- Key: HHH-3853 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3853 Project: Hibernate Core Issue Type: Bug Components: envers Environment: Hibernate - core 3.4.0-SNAPSHOT, Hibernate - envers (trunk build from today) Reporter: Amar Singh Attachments: one-to-one-pk.zip one-to-one mapping with primary key association doesn't seem to be working. Eg. Code: <?xml version="1.0"?> <!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"> <hibernate-mapping package="org.hibernate.envers.test.integration.onetoone.bidirectional" default-lazy="false"> <class name="BidirectionalRefIngPK" table="BIDIRECTIONAL_REFERENCING_ENTITY"> <id name="id" type="long" column="BIDIRECTIONAL_REFERENCING_ID" > <generator class="foreign"> <param name="property">reference</param> </generator> </id> <property name="data"/> <property column="BIDIRECTIONAL_REFERENCING_ID" generated="never" insert="false" lazy="false" name="id" type="long" update="false"/> <one-to-one name="reference" cascade="save-update" class="BidirectionalRefEdPK" constrained="true" /> </class> <class name="BidirectionalRefEdPK" table="BIDIRECTIONAL_REFERENCED_ENTITY"> <id name="longId" type="long" column="BIDIRECTIONAL_REFERENCED_ID"> <generator class="native"/> </id> <property name="data"/> <one-to-one name="referencing" cascade="all" class="BidirectionalRefIngPK" /> </class> </hibernate-mapping> When we try to load a BidirectionalRefIngPK, the underlying query invokes RelatedAuditExpression and since its not a foreign-key based one-to-one association the loading fails in method addToQuery of RelatedAuditExpression at line 52 (relatedEntity==null) with the following exception: Code: "This criterion can only be used on a property that is a relation to another property." TO REPRODUCE ~~~~~~~~~~~~~ Please find a zip file attached which has four files: - BidirectionalPrimaryAssociation.java (actual testng test case) - BidirectionalRefEdPK.java (Entity 1) - BidirectionalRefIngPK.java (Entity 2) - mappings.hbm.xml Please put the three java files in its package (org.hibernate.envers.test.integration.onetoone.bidirectional) and the mapping file in src/test/resources. Now when you run envers tests you should see the failure. Thanks for this great component ! -- 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, 10 months

8
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3414) fetch profiles

by Steve Ebersole (JIRA)

fetch profiles -------------- Key: HHH-3414 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3414 Project: Hibernate3 Issue Type: New Feature Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.4 The concept of fetch profiles as we are discussing here is basically to allow users to dynamically affect the mapped fetching strategy for associations at runtime. Consider the following example: <class name="Person"> ... <set name="addresses" lazy="true" fetch="subselect" ...> ... </set> </class> <class name="Address"> ... </class> This follows the normal recommendation to map associations as lazy and use a dynamic fetching strategy (ala HQL/Criteria) to modify this lazy behavior at runtime. The fetaure discussed here would allow the same behavior for loading as well: <hibernate-mapping> <fetch-profile name="person-details"> <fetch path="Person.addresses" style="join"/> </fetch-profile> </hibernate-mapping> Or: <hibernate-mapping> <class name="Person"> ... <fetch-profile name="person-details"> <fetch path="addresses" style="join"/> </fetch-profile> <set name="addresses" lazy="true" fetch="subselect" ...> ... </set> </class> </hibernate-mapping> Now, doing: session.enableFetchProfile( "person-details" ).get( Person.class, 1 )... will load Person#1 as well as their addresses in a single joined query. -- 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, 10 months

9
16
0 / 0

[Hibernate-JIRA] Created: (ANN-721) ManyToOne Persisting Cascade in Embeddable

by Endre Jeges (JIRA)

ManyToOne Persisting Cascade in Embeddable ------------------------------------------ Key: ANN-721 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-721 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Environment: Java version: java version "1.6.0_04" Java(TM) SE Runtime Environment (build 1.6.0_04-b12) Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode, sharing) Oracle Version: Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production PL/SQL Release 9.2.0.8.0 - Production "CORE 9.2.0.8.0 Production" TNS for Linux: Version 9.2.0.8.0 - Production NLSRTL Version 9.2.0.8.0 - Production hibernate: 3.2.6.ga hibernate-annotations: 3.3.1.ga hibernate-commons-annotations: 3.3.0.ga hibernate-entitymanager: 3.3.1.ga Reporter: Endre Jeges Attachments: pairTest.zip Hello, I have found something that is a bit strange. For @ManyToOne association properties in an @Embeddable class the cascade PERSIST, SAVE-UPDATE option is not working well (not sure for the other cascade types), if the entities associated with ManyToOne are transient. I have created a unit test to check it and I have it attached to this issue. It is a maven2 project, and needs Oracle to run it. If I save the associated entites, then everything works fine, also the data structure is created well. I have checked the forums and found similar problems, maybe they can help more then my post: http://forum.hibernate.org/viewtopic.php?t=965238 http://forum.hibernate.org/viewtopic.php?t=976534 http://forum.hibernate.org/viewtopic.php?t=978112 http://forum.hibernate.org/viewtopic.php?t=978138 http://forum.hibernate.org/viewtopic.php?t=983766 http://forum.hibernate.org/viewtopic.php?t=983780 http://forum.hibernate.org/viewtopic.php?t=983868 Details: @Entity class CodedPairHolder { @Id private Long id; @Column(name = "CODE", nullable = false, unique = true, updatable = false, length = 256) private String code; @CollectionOfElements @JoinTable(name = "CODED_PAIR_HOLDER_PAIR_SET", joinColumns = @JoinColumn(name = "CODED_PAIR_HOLDER_ID")) private final Set<PersonPair> pairs = new HashSet<PersonPair>(0); ........ constructors getters equals hashCode } @Embeddable class PersonPair { @ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }) @Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH, org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT }) @JoinColumn(name = "LEFT_PERSON_ID", nullable = false, updatable = false) private Person left; @ManyToOne(optional = false, fetch = FetchType.LAZY, cascade = { CascadeType.PERSIST, CascadeType.MERGE, CascadeType.REFRESH }) @Cascade( { org.hibernate.annotations.CascadeType.PERSIST, org.hibernate.annotations.CascadeType.MERGE, org.hibernate.annotations.CascadeType.REFRESH, org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.REPLICATE, org.hibernate.annotations.CascadeType.EVICT }) @JoinColumn(name = "RIGHT_PERSON_ID", nullable = false, updatable = false) private Person right; ........ constructors getters equals hashCode } @Entity class Person { @Id private Long id; @Column(name = "NAME", nullable = false, unique = true, updatable = false, length = 256) private String name; ........ constructors getters equals hashCode } The error message is: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: Person Regards, jeges -- 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, 10 months

7
16
0 / 0

[Hibernate-JIRA] Created: (HHH-2738) Eager fetch support for StatelessSession

by Christian Bauer (JIRA)

Eager fetch support for StatelessSession ---------------------------------------- Key: HHH-2738 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2738 Project: Hibernate3 Issue Type: Task Components: core Reporter: Christian Bauer class Node { @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name = "PARENT_NODE_ID", nullable = true) protected Node parent; } StatelessSession ss = getStatelessSession(); Node node = (Node) ss.get(Node.class, nodeId); [testng] org.hibernate.AssertionFailure: possible non-threadsafe access to the session [testng] at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:100) [testng] at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:854) [testng] at org.hibernate.loader.Loader.doQuery(Loader.java:729) [testng] at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) [testng] at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) [testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) [testng] at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) [testng] at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3042) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:158) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:153) [testng] at org.hibernate.impl.StatelessSessionImpl.get(StatelessSessionImpl.java:145) -- 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, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3674) Expose SchemaUpdate#haltOnError as a configuration property

by Chris Bredesen (JIRA)

Expose SchemaUpdate#haltOnError as a configuration property ----------------------------------------------------------- Key: HHH-3674 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3674 Project: Hibernate Core Issue Type: New Feature Components: documentation, metamodel Reporter: Chris Bredesen Assignee: Chris Bredesen Priority: Minor SchemaUpdate currently collects and logs any Exceptions caught during its work. While the Exceptions are logged, Hibernate is allowed to startup successfully. This feature request allows for a setting to flip this behavior such that Hibernate will not start if one or more Exceptions are encountered during SchemaUpdate (in test environments, of course). Proposed configuration option is hibernate.hbm2ddl.haltOnError -- 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, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4713) Avoid using same cache instance for storing CacheValue and evictAll notifications

by Galder Zamarreno (JIRA)

Avoid using same cache instance for storing CacheValue and evictAll notifications --------------------------------------------------------------------------------- Key: HHH-4713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4713 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.0-Beta-2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Store evictAll information in a separate infinispan cache instance in order to avoid doing stuff like this in BaseRegion.toMap which could be quite expensive in the context of SecondLevelCacheStatistics calculations: public Map toMap() { if (checkValid()) { // If copying causes issues, provide a lazily loaded Map Map map = new HashMap(); Set<Map.Entry> entries = cacheAdapter.toMap().entrySet(); for (Map.Entry entry : entries) { Object key = entry.getKey(); if (!CacheHelper.isEvictAllNotification(key)) { map.put(key, entry.getValue()); } } return map; } return Collections.EMPTY_MAP; } -- 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, 10 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-4694) Support "fake" many-to-one bidirectional relations

by Adam Warski (JIRA)

Support "fake" many-to-one bidirectional relations -------------------------------------------------- Key: HHH-4694 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4694 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski Assignee: Adam Warski Fix For: 3.5 Such relations are mapped with @OneToMany+@JoinColumn and @ManyToOne+@Column(insertable=false, updatable=false). This will be supported by an experimental @AuditMappedBy annotation. -- 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, 10 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2010