[Hibernate-JIRA] Created: (HHH-6593) Fetch joining subelements of a one-to-one or many-to-one association
by Christian Beikov (JIRA)
Fetch joining subelements of a one-to-one or many-to-one association
--------------------------------------------------------------------
Key: HHH-6593
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6593
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.6
Reporter: Christian Beikov
Priority: Critical
The problem is discussed on the forum a long time ago. I just found the topic and i wanted to report that this bug is still available in 3.6.6
https://forum.hibernate.org/viewtopic.php?f=1&t=987905&start=0
Here a concrete example from my usecase:
class A{
private B b;
}
class B{
private Map<String, C> map;
}
class C{
private String c;
}
Just imagine that the classes and fields would be annotated right ;)
Now the problem in my case was that i wanted a list of A elements with fetch joined B and of course it's map.
I tried the following query:
FROM A a LEFT OUTER JOIN FETCH a.b bElem LEFT OUTER JOIN bElem.map cMap
and i got a NullPointerException just like the users which posted in the given topic.
My workaround was:
FROM A a LEFT OUTER JOIN FETCH a.b bElem LEFT OUTER JOIN a.b.map cMap
The main problem now is, that i have a dynamic fetch profile system which won't work correctly if this issue is not solved.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[Hibernate-JIRA] Created: (HHH-6695) Error "Cannot create TypedQuery for query with more than one return" with named queries
by Oliver Siegmar (JIRA)
Error "Cannot create TypedQuery for query with more than one return" with named queries
---------------------------------------------------------------------------------------
Key: HHH-6695
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6695
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 4.0.0.CR4, 3.6.7, 3.6.8
Reporter: Oliver Siegmar
The already closed issues HHH-5348 and HHH-6591 only fixed the bug with standard (non-named) queries. Having a query like {code:sql}SELECT NEW org.test.MyClass( 'Foo', 123 ) FROM IrcEvent ev{code} as shown in HHH-6591 used by createQuery(), the bug has been fixed. Using the very same query as a named query by createNamedQuery() this exception is thrown:
{noformat}
java.lang.IllegalArgumentException: Cannot create TypedQuery for query with more than one return
at org.hibernate.ejb.AbstractEntityManagerImpl.createNamedQuery(AbstractEntityManagerImpl.java:684) ~[hibernate-entitymanager-4.0.0-20110929.060732-144.jar:4.0.0-SNAPSHOT]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0]
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0]
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0]
...
{noformat}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years
[Hibernate-JIRA] Created: (HHH-5275) Criteria.setLockMode does not work correctly
by Björn Moritz (JIRA)
Criteria.setLockMode does not work correctly
--------------------------------------------
Key: HHH-5275
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5275
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2, Oracle 10 (using org.hibernate.dialect.Oracle10gDialect
Reporter: Björn Moritz
Priority: Minor
Attachments: TestCase.zip
The LockMode set via Criteria.setLockMode does not generate a ' for update' SQL statement. In the org.hibernate.dialect.Dialect class only the LockOptions are used for determining a possible addition to the SQL statement if using pessimistic locking. This behaviour is different from Hibernate 3.1.3.
In the supplied TestCase two threads are reading the same database record; one of those threads should use pessimistic locking thereby blocking the other thread. But both threads can read the database record causing the test to fail.
--
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
[Hibernate-JIRA] Created: (HHH-2763) (lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
by S.Schnabl (JIRA)
(lazy) m:n relation + EventListener = AssertionFailure: collection [n-side] was not processed by flush()
--------------------------------------------------------------------------------------------------------
Key: HHH-2763
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2763
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5, 3.2.4.sp1
Environment: Windows-XP, Jboss 4.2.1GA, Hibernate 3.2.4SP1, EJB3
Reporter: S.Schnabl
Priority: Critical
Attachments: Testcase.zip
For more details see the attached testcase. I'm sorry, but in the short of time i only got a testcase for jboss-server 4.2. Please deploy the server.ear from /release-directory and then call the /src/client/TestCaseClient.java.
[Summarized]
It seems, that touching a lazy (Persistent-)Collection of at least a m:n relation inside a Hibernate event-listener always raises this error:
org.hibernate.AssertionFailure: collection [n-side] was not processed by flush()
[Explanation]
I have two entities A. and B. Both having a m:n relation between each other. Furthermore there is an PostUpdateListener, which iterates onUpdate of entitiy through all properties of updated entity.
[Testcase]
Both entities are linked with eachother (m:n). If i now do a simple update of a property of entity A --> MyPostUpdateListener will be called, which iterates through every property of the updated entity. In case of this property was a collection (= lazy PersistentCollection of m:n relation), hibernate initializes the collection for further work. I can now run through all objects of the collection, but after all work is done in listener, I get the following exception from postFlush:
Caused by: org.hibernate.AssertionFailure: collection [com.qualitype.testcase.server.ejb.entity.EntityB.entitiesOfA] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:205)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:333)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338)
at org.hibernate.ejb.AbstractEntityManagerImpl$1.beforeCompletion(AbstractEntityManagerImpl.java:515)
... 29 more
Attention: EntityB.entitiesOfA is the other-side collection of the m:n relation of the updated EntityA.
We are using hibernate-event listener system for auditing-purposes, so you should understand that touching every (element in the) collection is necessary for audit-purposes.
Seems for me like a serious bug. Need this fixed asap ...
--
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
[Hibernate-JIRA] Created: (HHH-5891) AuditReaderImpl.getRevisions result is not ordered as specified in Javadoc
by Thierry Monney (JIRA)
AuditReaderImpl.getRevisions result is not ordered as specified in Javadoc
--------------------------------------------------------------------------
Key: HHH-5891
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5891
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.6.1
Reporter: Thierry Monney
The Javadoc of org.hibernate.envers.AuditReader.getRevisions specifies that results are
{quote}
sorted in ascending order (so older revisions come first)??.
{quote}
The implementation in {{org.hibernate.envers.reader.AuditReaderImpl}} is as follows:
{{return createQuery().forRevisionsOfEntity(cls, entityName, false, true).addProjection(AuditEntity.revisionNumber()).add(AuditEntity.id().eq(primaryKey)).getResultList();}}
The Javadoc of {{AuditQueryCreator.forRevisionsOfEntity}} specifies that
{quote}
The results of the query will be sorted in ascending order by the revision number, unless an order or projection is added
{quote}
Since the implementation adds a projection on the revision number, no ordering is performed, which causes randomly ordered results to be returned.
The fix looks simple: just replace the above code with
{{return createQuery().forRevisionsOfEntity(cls, entityName, false, true).addProjection(AuditEntity.revisionNumber()).add(AuditEntity.id().eq(primaryKey)).addOrder(AuditEntity.revisionNumber().asc()).getResultList();}}
--
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
[Hibernate-JIRA] Created: (HHH-5257) @JoinTable results in redundant join in the generated SQL
by Sharath Reddy (JIRA)
@JoinTable results in redundant join in the generated SQL
---------------------------------------------------------
Key: HHH-5257
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5257
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Reporter: Sharath Reddy
Priority: Minor
Fix For: 3.6
Attachments: testcase.zip
An Account can have several Clients:
@Entity
@Table(name = "CLIENT")
public class Client implements Serializable {
private String street;
private String code;
private String city;
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private int id;
@ManyToOne
@JoinTable(name = "CLIENT_ACCOUNT",
joinColumns = {@JoinColumn(name = "FK_CLIENT", referencedColumnName = "ID")},
inverseJoinColumns = {@JoinColumn(name = "FK_ACCOUNT", referencedColumnName = "ID")})
private Account account;
.....
}
@Entity
@Table(name = "ACCOUNT")
public class Account implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private int id;
private String number;
private double balance;
@OneToMany (fetch = FetchType.EAGER, mappedBy="account")
private Set<Client> holders;
...
}
When we load the Account entity:
Account a1 = (Account) session.load(Account.class, accountId);
We see that there is a redundant join at the end - from the CLIENT table to the CLIENT_ACCOUNT table:
select
account0_.id as id2_1_,
account0_.balance as balance2_1_,
account0_.number as number2_1_,
holders1_.FK_ACCOUNT as FK1_2_3_,
client2_.id as FK2_3_,
client2_.id as id0_0_,
client2_.city as city0_0_,
client2_.code as code0_0_,
client2_.street as street0_0_,
client2_1_.FK_ACCOUNT as FK1_1_0_
from
ACCOUNT account0_
left outer join
CLIENT_ACCOUNT holders1_
on account0_.id=holders1_.FK_ACCOUNT
left outer join
CLIENT client2_
on holders1_.FK_CLIENT=client2_.id
left outer join
CLIENT_ACCOUNT client2_1_
on client2_.id=client2_1_.FK_CLIENT
where
account0_.id=?
--
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