[Hibernate-JIRA] Created: (HHH-7116) Ordered Criteria query that joins with an ordered mapped collection results in incorrect overall ordering
by Tommy Knowlton (JIRA)
Ordered Criteria query that joins with an ordered mapped collection results in incorrect overall ordering
---------------------------------------------------------------------------------------------------------
Key: HHH-7116
URL: https://hibernate.onjira.com/browse/HHH-7116
Project: Hibernate ORM
Issue Type: Bug
Components: core, query-criteria
Affects Versions: 4.1.0, 3.6.10
Reporter: Tommy Knowlton
A criteria query for Items that joins (with sub-criteria or alias) Bids, where mapped Bids collection is ordered [e.g., @OrderBy("bidamount desc")] and where the criteria query is ordered by Item descriptions [c.addOrder(Order.asc("description"))] will result in generated SQL having incorrect overall ordering: the ordering specified by the mapped association is output first, followed by the ordering specified on the criteria. Using the example, it ends up looking like "order by bid3_.AMOUNT desc, this_.DESCRIPTION asc".
There are actually two issues here. The first is that the association's ordering is overriding the criteria's ordering. Instead of having Items ordered alphabetically by description, and each Item's bids ordered by decreasing bid amounts, we have Items ordered from those having highest bids, down to those having lower bids, with alike bids ordered by description, alphabetically. It ends up being a simple matter to fix this issue in the "JoinWalker" base class.
The second issue is that in cases where a mapped association has an ordering specified, there is really an implied ordering by primary (or natural) key of the owning entity that has higher precedence than the association ordering. In the Items/Bids example, think about what happens to the criteria query if two items happen to have the same description text, and each has many bids: the result rows will be interleaved. It probably ends up being an implementation detail of the result transformer whether that matters or not, but I think that a "more correct" or at least less-surprising behavior would be for the "JoinWalker" to output orderby subclauses in such a way as to make the implied ordering (that keeps owning entities together in the resultset) explicit.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-6829) PooledLoOptimizer.generate() should be synchronized
by Manuel Dominguez Sarmiento (JIRA)
PooledLoOptimizer.generate() should be synchronized
---------------------------------------------------
Key: HHH-6829
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6829
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.8
Reporter: Manuel Dominguez Sarmiento
Priority: Critical
We recently switched to this ID generation optimizer in our highly concurrent production platform, and began getting random id / PK collision errors very often.
Checking the code, it's pretty obvious that the problem lies with generate() not being synchronized. All other optimizers (PooledOptimizer, LegacyHiLoAlgorithmOptimizer, HiLoOptimizer, etc.) are synchronized - PooledLoOptimizer should be as well.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[Hibernate-JIRA] Created: (HBX-948) org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
by Sathish P (JIRA)
org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
--------------------------------------------------------------------------------------------
Key: HBX-948
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-948
Project: Hibernate Tools
Issue Type: Bug
Components: consoleconfiguration
Affects Versions: 3.1.beta5
Environment: Eclipse
Reporter: Sathish P
WARN Finalizer org.hibernate.connection.DriverManagerConnectionProvider - problem closing pooled connection
java.sql.SQLException: Io exception: Socket closed
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:146)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:255)
at oracle.jdbc.driver.T4CConnection.logoff(T4CConnection.java:481)
at oracle.jdbc.driver.PhysicalConnection.close(PhysicalConnection.java:1203)
at org.hibernate.connection.DriverManagerConnectionProvider.close(DriverManagerConnectionProvider.java:152)
at org.hibernate.connection.DriverManagerConnectionProvider.finalize(DriverManagerConnectionProvider.java:142)
at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method)
at java.lang.ref.Finalizer.runFinalizer(Unknown Source)
at java.lang.ref.Finalizer.access$100(Unknown Source)
at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source)
--
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-5719) Applying projection to criteria with restricted subcriterias generates wrong SQL
by Victor Cherkassky (JIRA)
Applying projection to criteria with restricted subcriterias generates wrong SQL
--------------------------------------------------------------------------------
Key: HHH-5719
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5719
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.2.0.ga
Environment: Hibernate 3.2.0 GA
Reporter: Victor Cherkassky
Priority: Minor
Detailed issue description and solution is here http://facingtech.blogspot.com/2010_09_01_archive.html
I will describe only the technical aspect of the issue here.
Considuer the following model.
There is an entity {{User}}, which is in relation with {{Workplace}}. While {{Workplace}} has an {{Activity}} (the purpose of this workplace). Each {{Activity}} has a collection of {{Description}} entities ({{Description}} entities are just the same {{Activity}} description translated into several languages, thus having locale property).
Result of the query should look like this:
||User.name||Workplace.name||Activity.code||Description.text||
|John|Main office|R|Research|
|Polly|Main office|R|Research|
|Craig|Main office|R|Research|
Here is the criteria for getting that result:
{code}
Criteria criteria = session.createCriteria(User.class);
criteria.createAlias("workplace.activity.descriptions", "descriptionsAlias", Criteria.INNER_JOIN);
criteria.add(Restrictions.eq("descriptionsAlias.locale", "en_US"));
criteria.list();
{code}
It works just fine. Produces the table shown above and generates SQL like this:
{code}
select
this_.id as id18_3_,
this_.name as name18_3_,
this_.workplaceId as workplac3_18_3_,
workplace3_.id as id111_0_,
workplace3_.activityId as activityId111_0_,
workplace3_.name as name111_0_,
activity4_.id as id114_1_,
activity4_.code as code114_1_,
descriptio1_.id as id24_2_,
descriptio1_.locale as locale24_2_,
descriptio1_.text as text24_2_
from
user this_
left outer join
workplace workplace3_
on this_.workplaceId=workplace3_.id
left outer join
activity activity4_
on workplace3_.activityId=activity4_.id
inner join
description descriptio1_
on activity4_.id=descriptio1_.activityId
where
descriptio1_.locale=?
{code}
While if you want paging, you should make a rowcount projection first, so your query will look like this:
{code}
Criteria criteria = this.sessionFactory.getCurrentSession().createCriteria(User.class);}}
criteria.createAlias("workplace.activity.descriptions", "descriptionsAlias", criteria.INNER_JOIN);
criteria.add(Restrictions.eq("descriptionsAlias.locale", "en_US"));
criteria.setProjection(Projections.rowCount());
Integer rowCount = (Integer) criteria.uniqueResult();
{code}
And you expect Hibernate to produce this SQL:
{code}
select
count(*) as y0_
from
user this_
left outer join
workplace workplace3_
on this_.workplaceId=workplace3_.id
left outer join
activity activity4_
on workplace3_.activityId=activity4_.id
inner join
description descriptio1_
on activity4_.id=descriptio1_.activityId
where
descriptio1_.locale=?
{code}
But the SQL produced is this:
{code}
select
count(*) as y0_
from
user this_
where
descriptio1_.locale=?
{code}
I suppose that this is a bug, because you expect one behavior, while you get another. I don't think, that this is a big deal, but when you experience such an issue, it is time consuming to get it fixed.
Here is a workaround (or fix) of the issue. You should always assign aliases to all associated "links" of the "entities chain" of the path to an entity you want to restrict if you use projections. In other words, if you have anything in where clause and you are using projections, you should assign aliases to all associations between root entity and the entity, fields of which are used in where clause.
This criteria
{code}
Criteria criteria = this.sessionFactory.getCurrentSession().createCriteria(User.class);
criteria.createAlias("workplace", "workplaceAlias");
criteria.createAlias("workplaceAlias.activity", "activityAlias");
criteria.createAlias("activityAlias.descriptions", "descriptionsAlias", Criteria.INNER_JOIN);
criteria.add(Restrictions.eq("descriptionsAlias.locale", "en_US"));
criteria.setProjection(Projections.rowCount());
Integer rowCount = (Integer) criteria.uniqueResult();
{code}
Produces the right result
{code}
select
count(*) as y0_
from
user this_
inner join
workplace workplacea1_
on this_.workplaceId=workplacea1_.id
inner join
activity activityal2_
on workplacea1_.activityId=activityal2_.id
inner join
description descriptio3_
on activityal2_.id=descriptio3_.activityId
where
descriptio3_.locale=?
{code}
--
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: (OGM-112) ConcurrentModificationException while loading associations under load
by Sanne Grinovero (JIRA)
ConcurrentModificationException while loading associations under load
---------------------------------------------------------------------
Key: OGM-112
URL: http://opensource.atlassian.com/projects/hibernate/browse/OGM-112
Project: Hibernate OGM
Issue Type: Bug
Reporter: Sanne Grinovero
{quote}class: class java.util.ConcurrentModificationException
cause: null
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextEntry(HashMap.java:793)
at java.util.HashMap$KeyIterator.next(HashMap.java:828)
at java.util.AbstractCollection.addAll(AbstractCollection.java:305)
at org.hibernate.ogm.datastore.spi.Association.getKeys(Association.java:132)
at org.hibernate.ogm.loader.OgmLoader.getResultSet(OgmLoader.java:417)
at org.hibernate.ogm.loader.OgmLoader.doQuery(OgmLoader.java:248)
at org.hibernate.ogm.loader.OgmLoader.doQueryAndInitializeNonLazyCollections(OgmLoader.java:215)
at org.hibernate.ogm.loader.OgmLoader.loadCollection(OgmLoader.java:185)
at org.hibernate.ogm.loader.OgmBasicCollectionLoader.initialize(OgmBasicCollectionLoader.java:42)
at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:622)
at org.hibernate.event.internal.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:82)
at org.hibernate.internal.SessionImpl.initializeCollection(SessionImpl.java:1606)
at org.hibernate.collection.internal.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:379)
at org.hibernate.collection.internal.AbstractPersistentCollection.read(AbstractPersistentCollection.java:112)
at org.hibernate.collection.internal.PersistentSet.iterator(PersistentSet.java:180){quote}
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 9 months
[Hibernate-JIRA] Created: (HHH-4915) <list-index> base attribute ignored on insert for a bidirectional association (one-to-many)
by Olivier Lafontaine (JIRA)
<list-index> base attribute ignored on insert for a bidirectional association (one-to-many)
-------------------------------------------------------------------------------------------
Key: HHH-4915
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4915
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-CR-1, 3.3.2
Environment: Hibernate 3.3.2GA and 3.5.0-CR-1
Oracle Database
Reporter: Olivier Lafontaine
Attachments: hibernate-poc-jira.zip
My mapping looks like the following:
{code:xml}
<hibernate-mapping>
<class name="Parent">
<!-- SNIP -->
<list name="children" table="CHILD" cascade="all-delete-orphan">
<key column="ID_PARENT" not-null="true" />
<list-index base="1">
<column name="IDX" check="IDX > 0" />
</list-index>
<one-to-many class="Child" />
</list>
</class>
<class name="Child">
<!-- SNIP -->
<many-to-one name="parent" class="Parent" column="ID_PARENT"
not-null="true" insert="false" update="false" />
</class>
</hibernate-mapping>
{code}
As you can see from the mapping, we have a parent entity ({{Parent}}) referring child entities ({{Child}} using the {{children}} accessor). The index column ({{ORDER}}) is not an attribute in the child entity, so I referred to the second use case in section _6.3.3. Bidirectional associations with indexed collections_ of the reference guide to do my mapping.
Everything works except for the index base, it is always 0 based on insert. I've tried both Hibernate 3.3.2GA and the latest development version (3.5.0-CR-1), the issue can be reproduced in both.
I've joined a test case to reproduce the problem. While working on it, I realized there are updates after the inserts setting the correct index. However, we cannot change the database schema and there's a constraint on the index column enforcing a value > 0. So this issue is really important for us. I could manually handle the index values, but it would be so much easier to let Hibernate do it.
I've traced the problem and it seems that {{StatefulPersistenceContext#getIndexInParent(..)}} does not considers the index base. Why are updates necessary after the inserts? It looks to me like Hibernate could correctly set the index parameter on the insert statements.
--
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