[Hibernate-JIRA] Created: (ANN-843) Version increment not triggered on @OneToOne property modification having inverse owner
by Guenther Demetz (JIRA)
Version increment not triggered on @OneToOne property modification having inverse owner
---------------------------------------------------------------------------------------
Key: ANN-843
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-843
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.4.0.GA
Environment: Hibernate 3.3.1.GA , Microsoft SQL Server
Reporter: Guenther Demetz
Priority: Minor
Attachments: Testcase.jar
In the revised "Java Persistence with Hibernate" book by Christian Bauer and Gavin King on page 464
there's written following about versioning:
"If you use Hibernate as JPA provider ... every value-typed property modification .. triggers a version increment."
Now I saw that Version increment indeed is not triggered on @OneToOne properties having an inverse owner (= mappedBy setted).
This allows several concurrent transactions to set the association from same object towards different targets without having a OptimistickLockException at commit.
This violates the ToOne policy! (Hibernate detects the inconsistency later when loading the property from database:
org.hibernate.HibernateException: More than one row with the given identifier was found)
Please see attached junit-testcase for reproducing the problem.
regards
Guenther Demetz
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3872) Criteria on alias causes partial collection materialization
by Adrian Moos (JIRA)
Criteria on alias causes partial collection materialization
-----------------------------------------------------------
Key: HHH-3872
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3872
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.3.0.CR1
Reporter: Adrian Moos
I have a parent entity with a one-to-many assocation to a child entity:
<hibernate-mapping package="ch.bedag.a11.ccinfo.business.entity" default-lazy="false">
<class name="Parent" table="PARENT">
<id name="id" type="long" column="ID" unsaved-value="null">
<generator class="sequence">
<param name="sequence">SEQ_T_PARENT</param>
</generator>
</id>
<set name="children" cascade="all-delete-orphan" inverse="true">
<key column="PARENT_ID" foreign-key="CHILD_FK1"/>
<one-to-many class="Child"/>
</set>
</class>
<class name="Child"
<id name="id" type="long" column="ID" unsaved-value="null">
<generator class="sequence">
<param name="sequence">SEQ_T_CHILD</param>
</generator>
</id>
<property name="businessKey" column="BUSINESSKEY" not-null="true"/>
</class>
</hibernate-mapping>
I then do:
Criteria parentCriteria = aSession.createCriteria(Parent.class);
parentCriteria.createAlias("children", "c", CriteriaSpecification.LEFT_JOIN);
parentCriteria.setResultTransformer(CriteriaSpecification.DISTINCT_ROOT_ENTITY);
parentCriteria.add(Restrictions.eq("c.businessKey", 123456789));
List parents = parentCriteria.list();
Expected behaviour: Since each parent in parents is a materialized entity, I'd expect its children set to contain all its children.
Observed behaviour: It contains only children with matching business key.
Is my expectation correct?
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3230) getEntityName() throws org.hibernate.TransientObjectException: proxy was not associated with the session
by Howard M. Lewis Ship (JIRA)
getEntityName() throws org.hibernate.TransientObjectException: proxy was not associated with the session
--------------------------------------------------------------------------------------------------------
Key: HHH-3230
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3230
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.2
Environment: Mac OS X, JDK 1.5
Reporter: Howard M. Lewis Ship
I'm retrieving an entity that contains a OneToMany relationship.
The master entity is retrieved, within a transaction, via Session.get(Class,Serializable).
@Entity
public class MapUnitSurvey extends ActiveDO
{
@ManyToOne(fetch = FetchType.LAZY)
private VegetationType vegetationType;
}
@Entity
public class VegetationType extends AbstractEnum
{
}
ActiveDO and AbstractEnum are abstract base classes with @MappedSuperclass.
I retrieve the vegationType:
VegetationType type = survey.getVegetationType();
Then I need the type's entity name
String entityName = session.getEntityName(type);
This fails with the TransientObjectException.
Inspecting with the debugger, I see that type is a CGLIB-enhanced proxy, and that there's a fully initialized bean in the target field of the proxy. I'll attach a screenshot of some debugging data.
In summary; the entity was retrieved via a lazy fetch, appears the be correct, seems to be in the session and yet the exception occurs.
I've tried to resolve this by re-fetching the object from the session, and a few other tries, with no luck.
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3332) Hibernate duplicate then child entity's on merge
by Rodrigo de Assumpção (JIRA)
Hibernate duplicate then child entity's on merge
------------------------------------------------
Key: HHH-3332
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3332
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6
Environment: JDK 1.6
Oracle 9i
Hibernate 3.2.6
Hibernate Annotations 3.3.1
Hibernate EntityManager 3.3.2
Standalone Running
Reporter: Rodrigo de Assumpção
Priority: Critical
The method merge from EntityManager causes a duplication of child entity's.
class Father:
@OneToMany(mappedBy = "father", cascade={CascadeType.ALL}, fetch=FetchType.LAZY)
private List<Child> childList;
class Child:
@ManyToOne @JoinColumn(name = "ID_FATHER")
private Father father;
class BugTest
EntityManagerFactory emf = Persistence.createEntityManagerFactory("JpaTestHB");
EntityManager em = emf.createEntityManager();
Father f = (Father) em.createQuery("SELECT f FROM Father f WHERE f.id = 1").getSingleResult();
Child c = new Child();
c.setFather(f);
f.getChildList().add(c);
em.getTransaction().begin();
em.merge(f);
em.getTransaction().commit();
The execution of BugTest Class causes tow insert's on table "child".
If you change the fetch mode to EAGER (into Father class) the problem not occurs.
I make the same test with Toplink, and it make a unique insert, normal.
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3608) DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB
by Matthias Gommeringer (JIRA)
DB sequence numbers are not unique when using the pooled SequenceStyleGenerator in multiple JVMs with the same DB
-----------------------------------------------------------------------------------------------------------------
Key: HHH-3608
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3608
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.2.6
Environment: Hibernate 3.2.6, Oracle (any version)
Reporter: Matthias Gommeringer
Priority: Blocker
Attachments: PooledOptimizerTest.java
We have several Application Servers (=JVMs) running each of them using Hibernate-Objects with the SequenceStyleGenerator+pooled configured. In unpredictable time intervals it happens that hibernate assigns the same ID to two completely different objects which results in a UniqueConstraintViolation exception from the database. Here an example with a description where hibernate fails:
DB-Sequence setup:
start=0
increment=2
PooledOptimizer.generate() with 2 threads (first assignment of hiValue/value):
JVM-1 JVM-2
value=0=callback.nextval
value=2=callback.nextval
hiValue=4=callback.nextval
hiValue=6=callback.nextval
The problem's cause is in the PooledOptimizer.generate: when it initializes
the value+hiValue for the first time it invokes callback.nextValue() twice which
may provide values that do not belong to each other. The reason is that
between the assignment of "value" and "hiValue" another JVM can retrieve a
DB sequence value from the callback which leads to an inconsistent "value" and "hiValue"
relation (see example above).
A fix that works for multiple JVMs would be to invoke the "callback.getNextValue()" maximum once
per "optimizer.generate()" call:
public synchronized Serializable generate(AccessCallback callback) {
if ( hiValue < 0 ) {
value = callback.getNextValue();
hiValue = value + incrementSize;
}
else if ( value >= hiValue ) {
value = callback.getNextValue();
hiValue = value + incrementSize;
}
return make(value++);
}
I attached a testcase that prooves the described problem (you can see that the IDs "2" and "3" are assigned two times).
I would be very thankful if this problem could be fixed very soon since it is a showstopper which
occurs very unpredictably.
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3551) Boolean substitution in informix
by Rouvignac (JIRA)
Boolean substitution in informix
--------------------------------
Key: HHH-3551
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3551
Project: Hibernate Core
Issue Type: Bug
Components: query-sql
Affects Versions: 3.3.1
Environment: Hibernate 3.2
Informix 9.40
Reporter: Rouvignac
HQL Query :
select order from Order order where order.printed = ?
Parameter :
true, false, Boolean.TRUE or Boolean.FALSE
When the request is executed we get the following error :
SQLSTATE: IX000
SQL CODE: -674
674: Routine (equal) can not be resolved.
If as parameter we use "t" ot "f" everything works fine but it will not work with other DB.
As a workaround we can use :
property name="hibernate.query.substitutions">true t, false f</property>
I investigated in Dialects :
Dialect.java
public String toBooleanValueString(boolean bool) {
return bool ? "1" : "0";
}
PostgreSQLDialect.java
public String toBooleanValueString(boolean bool) {
return bool ? "true" : "false";
}
InformixDialect.java uses Dialect.java toBooleanValueString method.
In my mind toBooleanValueString should be added to InformixDialect.java as follow :
public String toBooleanValueString(boolean bool) {
return bool ? "t" : "f";
}
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3524) setFetchMode ignored if using createCriteria
by Peter Weemeeuw (JIRA)
setFetchMode ignored if using createCriteria
--------------------------------------------
Key: HHH-3524
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3524
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 8
Reporter: Peter Weemeeuw
Hi,
It seems that criteria.setFetchMode gets ignored if you combine it with createCriteria to add a restriction.
This works as expected:
DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class);
c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN);
But in this case the join doesn't happen (and I get a LazyInstantiationException further on).
DetachedCriteria c = DetachedCriteria.forClass(MenuItem.class);
c.setFetchMode("menuItemSubscriptions", FetchMode.JOIN);
c.createCriteria("menuItemSubscriptions").add(
Restrictions.eq("location", "B")
);
This does not happen if I set lazy="false" in the mappings
file.
Regards,
Peter
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (ANN-747) @CollectionOfElements does not cascade on delete
by Nicole Rauch (JIRA)
@CollectionOfElements does not cascade on delete
------------------------------------------------
Key: ANN-747
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-747
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.1.GA
Environment: Hibernate 3.2.6 GA
Database: H2 1.0.72
Reporter: Nicole Rauch
Consider the following constellation:
@Embeddable
public class Foo {
// ...
}
@Entity
public class Bar {
@CollectionOfElements
private Set<Foo> myFoos;
// ...
}
When I persist a Bar object that contains some Foos, and when I later decide to delete the Bar object, I get a foreign key constraint violation error message because the Foo objects, which contain a reference to the Bar object that owns them, are not deleted automatically. I would expect the default behaviour to be "on delete cascade" because the Foo objects are embeddables, thus they cannot exist on their own without the Bar object that owns them. But there is no way to tell Hibernate to cascade:
- the @OnDelete annotation is only allowed for OneToMany relations
- the @Cascade annotation is being ignored
- there is no "cascade" property for the CollectionOfElements
So my question is: Why does the cascading not occur automatically, and how do I tell Hibernate to cascade anyways?
Thanks a lot in advance,
Nicole
--
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
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-3273) One-to-Many relationship not working with custom Loader
by Darren Hicks (JIRA)
One-to-Many relationship not working with custom Loader
--------------------------------------------------------
Key: HHH-3273
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3273
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.6, 3.2.5, 3.2.4, 3.2.3, 3.2.2, 3.2.1
Environment: hibernate-3.2.6.jar
Reporter: Darren Hicks
Within the context of a One-to-Many relationship, NamedQueryCollectionInitializer .initialize() never actually populates the PersistantBag on the parent after it calls query.setCollectionKey( key ).setFlushMode( FlushMode.MANUAL ).list() to retrieve the children.
This is documented in the forums here: http://forums.hibernate.org/viewtopic.php?t=986428
Additionally, the poster has a fix posted which may solve the problem, or at least lay out the groundwork for a solution. Here is the proposed implementation of NamedQueryCollectionInitializer.initialize():
public void initialize(Serializable key, SessionImplementor session)
throws HibernateException {
if (log.isDebugEnabled()) {
log.debug("initializing collection: " + persister.getRole()
+ " using named query: " + queryName);
}
// TODO: is there a more elegant way than downcasting?
AbstractQueryImpl query = (AbstractQueryImpl) session
.getNamedSQLQuery(queryName);
if (query.getNamedParameters().length > 0) {
query.setParameter(query.getNamedParameters()[0], key, persister
.getKeyType());
} else {
query.setParameter(0, key, persister.getKeyType());
}
List list = query.setCollectionKey(key).setFlushMode(FlushMode.MANUAL)
.list();
// Uh, how 'bout we save the collection for later retrieval?
CollectionKey collectionKey = new CollectionKey(persister, key, session
.getEntityMode());
for (Object object : session.getPersistenceContext()
.getCollectionsByKey().keySet()) {
if (collectionKey.equals(object)) {
PersistentCollection persistentCollection = session
.getPersistenceContext().getCollection(collectionKey);
Serializable[] serializables = new Serializable[list.size()];
for (int i = 0; i < list.size(); i++) {
serializables[i] = persister.getElementType().disassemble(
list.get(i), session,
persistentCollection.getOwner());
}
persistentCollection.initializeFromCache(persister,
serializables, persistentCollection.getOwner());
persistentCollection.setSnapshot(key, persistentCollection
.getRole(), serializables);
persistentCollection.afterInitialize();
session.getPersistenceContext().getCollectionEntry(
persistentCollection).postInitialize(
persistentCollection);
}
}
}
--
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
13 years, 9 months