February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7120) Bind PluralAttributeBinding for sets of basic elements with property-ref

by Gail Badner (JIRA)

Bind PluralAttributeBinding for sets of basic elements with property-ref ------------------------------------------------------------------------ Key: HHH-7120 URL: https://hibernate.onjira.com/browse/HHH-7120 Project: Hibernate ORM Issue Type: Sub-task Reporter: Gail Badner Assignee: Gail Badner -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6525) Integrate Set-style plural attributed into persisters

by Gail Badner (JIRA)

Integrate Set-style plural attributed into persisters ----------------------------------------------------- Key: HHH-6525 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6525 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7052) Bind PluralAttributeKeyBinding

by Gail Badner (JIRA)

Bind PluralAttributeKeyBinding ------------------------------ Key: HHH-7052 URL: https://hibernate.onjira.com/browse/HHH-7052 Project: Hibernate ORM Issue Type: Sub-task Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 5.0.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-471) Ability to "filter" entities from the search indexes

by Dobes Vandermeer (JIRA)

Ability to "filter" entities from the search indexes ---------------------------------------------------- Key: HSEARCH-471 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-471 Project: Hibernate Search Issue Type: New Feature Components: mapping Affects Versions: 3.1.1.GA Reporter: Dobes Vandermeer Priority: Minor In our system we have entities that are searched but not all of them are available for search - some of them are flagged as "removed". It would improve the efficiency of our search subsystem if we could implement a kind of "filter" that blocked these entities from being added to the search index, since we wouldn't have to make that a search term and our indexes would be somewhat smaller. -- 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, 1 month

5
31
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1050) DocumentId ignored in case of EmbeddedId

by Marc Schipperheyn (JIRA)

DocumentId ignored in case of EmbeddedId ---------------------------------------- Key: HSEARCH-1050 URL: https://hibernate.onjira.com/browse/HSEARCH-1050 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 4.1.0.Beta2, 4.0.0.Final Reporter: Marc Schipperheyn Priority: Blocker When a class contains both a @DocumentId and an @EmbeddedId set at different fields, Hibernate Search should use the DocumentId field. However, I'm noticing in 4.1.0Beta2 that in this case, the EmbeddedId field is used. In my case this leads to a org.hibernate.search.bridge.BridgeException: Exception while calling bridge#objectToString class: nl.project.model.NetworkCandidateLink field bridge: id at org.hibernate.search.bridge.util.impl.ContextualExceptionBridge.buildBridgeException(ContextualExceptionBridge.java:78) at org.hibernate.search.bridge.util.impl.ContextualException2WayBridge.objectToString(ContextualException2WayBridge.java:84) at org.hibernate.search.batchindexing.impl.EntityConsumerLuceneWorkProducer.index(EntityConsumerLuceneWorkProducer.java:164) at org.hibernate.search.batchindexing.impl.EntityConsumerLuceneWorkProducer.indexAllQueue(EntityConsumerLuceneWorkProducer.java:134) at org.hibernate.search.batchindexing.impl.EntityConsumerLuceneWorkProducer.run(EntityConsumerLuceneWorkProducer.java:105) at org.hibernate.search.batchindexing.impl.OptionallyWrapInJTATransaction.run(OptionallyWrapInJTATransaction.java:112) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassCastException: nl.project.model.NetworkCandidateLinkId cannot be cast to java.lang.String at org.hibernate.search.bridge.builtin.StringBridge.objectToString(StringBridge.java:39) at org.hibernate.search.bridge.builtin.impl.TwoWayString2FieldBridgeAdaptor.objectToString(TwoWayString2FieldBridgeAdaptor.java:48) at org.hibernate.search.bridge.util.impl.ContextualException2WayBridge.objectToString(ContextualException2WayBridge.java:77) ... 7 more I'm failry certain this was working correctly in 3.x The class configuration is as follows: @Entity @Table @AssociationOverrides({ @AssociationOverride(name = "pk.network", joinColumns = @JoinColumn(name = "nwId")), @AssociationOverride(name = "pk.candidate", joinColumns = @JoinColumn(name = "cId")) }) @Indexed public class NetworkCandidateLink implements Serializable{ private NetworkCandidateLinkId pk = new NetworkCandidateLinkId(); @EmbeddedId public NetworkCandidateLinkId getPk() { return pk; } public void setPk(NetworkCandidateLinkId pk) { this.pk = pk; } @DocumentId @Transient public String getId(){ return pk.getCandidate().getId() + "_" + pk.getNetwork().getId(); } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1030) Reindexing embedded Collection FieldBridge throws a LazyInitializationException and stop reindexation

by Laurent Almeras (JIRA)

Reindexing embedded Collection FieldBridge throws a LazyInitializationException and stop reindexation ----------------------------------------------------------------------------------------------------- Key: HSEARCH-1030 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1030 Project: Hibernate Search Issue Type: Bug Environment: Hibernate Search 4.0 Fedora 16 JVM Java Sun (build 1.6.0_29-b11) 64bits Reporter: Laurent Almeras When an entity owns an @IndexedEmbedded property which points to an CollectionBridge, then mass-reindex throws an LazyInitializationException and stop the whole class reindex. I investigate the issue, and it appears that document-builder thread only initialize first level collections, and not the 2-level depth collections indexed with a CollectionBridge. See https://forums.hibernate.org/viewtopic.php?f=9&t=1013886&sid=a76521d7270e... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-5299) Multi-Level cascading of unsaved instances with bidirectional associations fails with TransientObjectException

by Carl-Eric Menzel (JIRA)

Multi-Level cascading of unsaved instances with bidirectional associations fails with TransientObjectException -------------------------------------------------------------------------------------------------------------- Key: HHH-5299 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5299 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: Tested with OracleXE and H2DB, Hibernate Core 3.3.2, Hibernate Entity Manager 3.4.0 Reporter: Carl-Eric Menzel Priority: Critical Attachments: 0001-fixed-no-cascading-check-to-also-accept-entities-wit.patch, cascadetest.zip Given the following classes (pseudocode, full source in the attached zipfile): Top { @OneToMany(cascade = { CascadeType.ALL }, mappedBy = "top") List<Middle> middles } Middle { @ManyToOne Top top @OneToOne(cascade = { CascadeType.ALL }) @JoinColumn(name = "BOTTOM_ID") Bottom bottom } Bottom { @OneToOne(mappedBy = "bottom") Middle middle } The following code fails on the second flush with a TransientObjectException: Top top = new Top(); em.persist(top); em.flush(); // top is now attached, status MANAGED Middle middle = new Middle(1l); middle.setBottom(new Bottom()); top.addMiddle(middle); Middle middle2 = new Middle(2l); middle2.setBottom(new Bottom()); top.addMiddle(middle2); // both middles and bottoms are transient but should be saved by cascade em.flush(); // boom! The relevant part of the error is: org.hibernate.TransientObjectException: object references an unsaved transient instance - save the transient instance before flushing: test.Bottom.middle -> test.Middle at org.hibernate.engine.CascadingAction$9.noCascade(CascadingAction.java:376) at org.hibernate.engine.Cascade.cascade(Cascade.java:163) The same code works without exception when using EclipseLink instead of Hibernate EntityManager, so I am assuming that the test code is valid. Some debugging revealed that CascadingAction.PERSIST_ON_FLUSH.noCascade() checks the inverse association from Bottom to Middle. It then calls a private method isInManagedState to verify that this association does not reference an unsaved instance. It does this by checking the entities EntityEntry.getStatus() value, which it expects to be MANAGED or READ_ONLY. At this time, however, the Middle instance is in the middle (no pun intended) of its own cascading save cycle and therefore its status is SAVING. This, to me, seems to be a valid session-attached status, so isInManagedState() should also accept this state. The attached patch against Hibernate Core 3.3.2 implements just that, and this change makes the above example code work as expected. The Hibernate test suite did not complain, so I am reasonably sure I did not break anything else. See also the attached cascadetest.zip for a ready-to-use testcase that demonstrates the error with Hibernate Core 3.3.2. Change the dependency in the supplied pom.xml to a patched version of Hibernate Core, and the test will no longer fail. Carl-Eric Menzel C1 SetCon GmbH -- 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, 1 month

6
18
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Strong Liu (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Strong Liu commented on HHH-1512: --------------------------------- okay, I had a chat with a friend who has lots of DB2 experience, he said > with *rr*, the whole table would be locked w/o index involved. > with *rs*, only selected rows would be locked. 1：tx1: db2 +c "select * from ck where id=3 with rr use and keep update locks" success, U lock on the table. 2：tx2: db2 +c "select * from ck where id=3 with rr use and keep update locks" U lock wait for table, since table already has a U lock from tx1, and U locks are not compatible with an U lock, so, waiting for tx1 finish ---------------------- > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7100) ColumnAttributeSourceImpl.isNullable() returns false for collection key

by Gail Badner (JIRA)

ColumnAttributeSourceImpl.isNullable() returns false for collection key ----------------------------------------------------------------------- Key: HHH-7100 URL: https://hibernate.onjira.com/browse/HHH-7100 Project: Hibernate ORM Issue Type: Bug Components: metamodel Reporter: Gail Badner Fix For: 5.0.0 ColumnAttributeSourceImpl.isNullable() should return true for collection key column. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1051) Refactor package names under org.hibernate.search in hibernate-search-engine module

by Hardy Ferentschik (JIRA)

Refactor package names under org.hibernate.search in hibernate-search-engine module ----------------------------------------------------------------------------------- Key: HSEARCH-1051 URL: https://hibernate.onjira.com/browse/HSEARCH-1051 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 4.1.0.Beta2 Reporter: Hardy Ferentschik The packages under _org.hibernate.search_ are missing loosing logical structuring and there are generally to many. Some suggestions for a refactoring might be: * create _org.hibernate.search.indexing_ and move batchindexing in there (maybe just as batch) * Move _analyzer_ and _bridge_ into _org.hibernate.search_ as well * Move _filter_ under _query_ ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
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 2012