November 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5695) Hibernate complains about an unknown mappedBy property when mapping a bidirectional OneToOne relation with a derived identifier

by Pascal Thivent (JIRA)

Hibernate complains about an unknown mappedBy property when mapping a bidirectional OneToOne relation with a derived identifier ------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5695 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5695 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.6.0, 3.6.0.CR2, 3.6.0.CR1, 3.5.6, 3.6.0.Beta4, 3.6.0.Beta3, 3.5.5, 3.6.0.Beta2, 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final Environment: Hibernate 3.5+, any database. Reporter: Pascal Thivent Attachments: HHH-5695.zip I have a OneToOne mapping between Foo and Bar where Bar uses a derived identifier. So Bar is the "dependent" entity and has a single primary key attribute which is mapped by the relationship attribute (i.e. using `Id` on the `OneToOne` relationship). Foo is mapped like this: {code} @Entity public class Foo { @Id @GeneratedValue private Long id; private String name; @OneToOne(mappedBy="foo", cascade=CascadeType.ALL) private Bar bar; public Long getId() { return id; } //... } {code} and Bar: {code} @Entity public class Bar { @Id @OneToOne @JoinColumn(name="BAR_ID") private Foo foo; //... } {code} This mapping is described in the section 2.4.1.2 of the JPA 2.0 specification, Example 4, case (a) and works with the RI (run {{mvn test -Peclipselink,h2}} on the attached project). However, Hibernate fails to initialize and complains about the mappedBy attribute: {code} Caused by: org.hibernate.AnnotationException: Unknown mappedBy in: com.acme.Foo.bar, referenced property unknown: com.acme.Bar.foo at org.hibernate.cfg.OneToOneSecondPass.doSecondPass(OneToOneSecondPass.java:159) at org.hibernate.cfg.Configuration.originalSecondPassCompile(Configuration.java:1686) at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1393) at org.hibernate.cfg.Configuration.buildMappings(Configuration.java:1345) at org.hibernate.ejb.Ejb3Configuration.buildMappings(Ejb3Configuration.java:1477) at org.hibernate.ejb.EventListenerConfigurator.configure(EventListenerConfigurator.java:193) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:1096) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:278) at org.hibernate.ejb.Ejb3Configuration.configure(Ejb3Configuration.java:362) ... 24 more {code} Run {{mvn test}} to reproduce. -- 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

11 years, 11 months

6
20
0 / 0

[Hibernate-JIRA] (HHH-7803) Re-think the method of automatically finding Embeddables

by Brett Meyer (JIRA)

11 years, 11 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6361) Collection events may contain wrong stored snapshot after merging a detached entity into the persistencecontext

by Erik-Berndt Scheper (JIRA)

Collection events may contain wrong stored snapshot after merging a detached entity into the persistencecontext --------------------------------------------------------------------------------------------------------------- Key: HHH-6361 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6361 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.5 Reporter: Erik-Berndt Scheper Priority: Minor After the merge process, driven by the {{DefaultMergeEventListener}}, it can happen that the Hibernate collection events contain references to an incorrect stored snapshot. This is both the case for the {{PersistentCollection}} and the {{CollectionEntry}}, as returned by {{session.getPersistenceContext().getCollectionEntry(persistentCollection)}} By itself, this looks like a minor issue. However, this leads to severe problems when Envers is used. This bug causes HHH-6349, which results in inconsistent (invalid) audit trails and possibly AssertionFailures when the {{ValidityAuditStrategy}} is used. I am pretty sure the same bug exists in the 4.0.0 Betas, since I have an Envers testcase for testng (3.6 branch) and junit4 (master) which both exhibit the same behaviour. However, I haven't looked in the changes in the merge process in 4.0.0 betas (compared to 3.6.x). I am currently preparing a testcase for the Hibernate testsuite (complimentary to the Envers testcases) together with a suggested fix, but this takes a bit more work than I anticipated. -- 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

11 years, 11 months

5
8
0 / 0

[Hibernate-JIRA] (HHH-7759) named queries not read by hbm source

by Brett Meyer (JIRA)

11 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] (HHH-7610) Option for setting @Embedded field null when all columns are NULL

by Ondra Žižka (JIRA)

11 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7235) Support null NaturalId values in loadEntityIdByNaturalId query

by Guenther Demetz (JIRA)

Support null NaturalId values in loadEntityIdByNaturalId query -------------------------------------------------------------- Key: HHH-7235 URL: https://hibernate.onjira.com/browse/HHH-7235 Project: Hibernate ORM Issue Type: Improvement Components: core Affects Versions: 4.1.2, 4.1.1, 4.1.0 Reporter: Guenther Demetz As it is allowed to persist and commit null naturalId values (for example null String values), it would also be nice to can sucessful lookup for those values. Currently the where-clause of the lookup-query does not consider the eventuality of null values, which in sql require an extra handling (using 'is' keyword instead of '=' sign). The needed code change is simple, see pull request. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 11 months

3
10
0 / 0

[Hibernate-JIRA] (HHH-7666) Replace unit tests' use of configuration()

by Brett Meyer (JIRA)

11 years, 11 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5436) different lock deepness for joined subclass

by kakusi kakusi (JIRA)

different lock deepness for joined subclass ------------------------------------------- Key: HHH-5436 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5436 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.2, 3.2.5 Environment: Oracle 10g Reporter: kakusi kakusi Hi, we use hibernate, oracle and pessimstic locking, to avoid concurrent modification through different threads. This worked fine for a while. But now we sometimes get deadlocks. We analyzied and found the cause: we produced locks with different deepnesses for objects of type joined subclass. An example for our kind of mapping: {noformat} <class name="TraceObject" table="TraceObjects"> <cache usage="read-write" /> <id name="objectId" column="objectId" type="long"> <generator class="native"> <param name="sequence">TraceObjectsSeq</param> </generator> </id> <timestamp name="dbVersionControl" /> ... </class> <joined-subclass name="VehicleObject" table="VehicleObjects" extends="TraceObject"> <key column="id" /> ... </joined-subclass>{noformat} Method: {{session.get(Class clazz, Serializable id, LockMode lockMode);}} Created Select-Statement: {{SELECT traceobjec0_.objectId ... FROM TraceObjects traceobjec0_ LEFT OUTER JOIN VehicleObjects traceobjec0_3_ ON traceobjec0_.objectId=traceobjec0_3_.id WHERE traceobjec0_.objectId=? FOR UPDATE;}} Effect: This locks the relevant data in table TraceObjects and joined table VehicleObjects. Method: {{session.get(Class clazz, Serializable id);}} {{session.lock(Object object, LockMode lockMode);}} Created Select-Statement: {{select traceobjec0_.objectId ... from TraceObjects traceobjec0_ left outer join VehicleObjects traceobjec0_3_ on traceobjec0_.objectId=traceobjec0_3_.id where traceobjec0_.objectId=?;}} {{select objectId from TraceObjects where objectId =? for update;}} Effect: This only locks the relevant data in table TraceObjects. We think this is a bug, because all techniques to lock should create the same lock type (only locking the parent table). -- 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

11 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] (OGM-254) PersistentTableBulkIdStrategy.exportTableDefinitions() throws NullPointerException with OGM

by Patrik Varga (JIRA)

11 years, 11 months

3
7
0 / 0

[Hibernate-JIRA] (HHH-7488) Separate queries by semicolon instead of new line symbol

by Dmitry Geraskov (JIRA)

11 years, 11 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues November 2012