[Hibernate-JIRA] Created: (ANN-625) @OrderBy usage on a joined classes (when using join table) produces incorred SQL syntax.
by Dima Gutzeit (JIRA)
@OrderBy usage on a joined classes (when using join table) produces incorred SQL syntax.
----------------------------------------------------------------------------------------
Key: ANN-625
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-625
Project: Hibernate Annotations
Issue Type: Bug
Affects Versions: 3.3.0.ga
Reporter: Dima Gutzeit
Please consider the following mapping :
@ManyToMany(cascade = {CascadeType.PERSIST, CascadeType.MERGE}, fetch = FetchType.LAZY)
@IndexColumn(name = "ListIndex")
@JoinTable(name = "odp_rulemanipulatorjoin", joinColumns = @JoinColumn(name = "RoutingRuleId"), inverseJoinColumns = @JoinColumn(name = "ManipulatorComponentId"))
@OrderBy(value = "priority asc")
public List<RoutingManipulationComponent> getManipulators() {
if (manipulators == null) {
manipulators = new ArrayList<RoutingManipulationComponent>();
}
return manipulators;
}
***********************************
@Entity(name = "RoutingManipulationComponent")
@DiscriminatorValue("RoutingManipulationComponent")
public abstract class RoutingManipulationComponent extends RoutingComponent implements Initializable {
/**
* Applies the manipulation to the given context.
*
* @param context the routing context to manipulate
* @return true if any manipulation was applied, false if no manipulation
* occurred
*/
public abstract boolean apply(RoutingContext context);
}
******************************************
@Entity(name = "RoutingComponent")
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "RoutingComponentType", discriminatorType = DiscriminatorType.STRING)
@DiscriminatorValue("RoutingComponent")
@Table(name = "odp_routingcomponent")
public abstract class RoutingComponent extends DialPlanProvisionalEntity {
@Deprecated
public RoutingComponent() {
// blank
}
/**
* @param name
* @param description
*/
public RoutingComponent(String name, String description) {
super(name, description);
}
}
*******************************
@MappedSuperclass
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
public abstract class DialPlanProvisionalEntity extends ProvisionalEntity
implements Initializable {
private Long entityId;
private boolean visible = true;
private int priority;
/**
* Not for direct instantiation - this constructor also serves as public
* constructor for hibernate, jax-ws etc. <br>
*/
@Deprecated
public DialPlanProvisionalEntity() {
this("(no name set)", "(no description set)");
}
/**
* @param name
* @param description
*/
public DialPlanProvisionalEntity(String name, String description) {
creationDate = GregorianCalendar.getInstance(); // now
}
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
@Override
public Long getId() {
return entityId;
}
@Override
public void setId(Long ruleCollectionId) {
this.entityId = ruleCollectionId;
}
/**
* @return Returns the priority.
*/
public int getPriority() {
return priority;
}
/**
* @param priority The priority to set.
*/
public void setPriority(int priority) {
this.priority = priority;
}
@Override
public boolean equals(Object o) {
if (this == o) {
return true;
}
if (o == null || Hibernate.getClass(this) != Hibernate.getClass(o)) {
return false;
}
final ProvisionalEntity other = (ProvisionalEntity) o;
return MiscUtils.equalOrBothNull(this.getName(), other.getName());
}
@Override
public int hashCode() {
String name = this.getName();
return getClass().getName().hashCode() + 13 * name.hashCode();
}
}
The above mapping should use the "priority" field to the ordering.
SQL that is produced is :
select criteria0_.RoutingRuleId as RoutingR1_1_, criteria0_.CriteriaComponentId as Criteria2_1_,
criteria0_.ListIndex as ListIndex1_,
routingcri1_.id as id73_0_,
routingcri1_.creationDate as creation3_73_0_,
routingcri1_.description as descript4_73_0_,
routingcri1_.lastModificationDate as lastModi5_73_0_,
routingcri1_.name as name73_0_,
routingcri1_.predefined as predefined73_0_,
routingcri1_.status as status73_0_,
routingcri1_.priority as priority73_0_,
routingcri1_.visible as visible73_0_,
routingcri1_.matcher_id as matcher25_73_0_,
routingcri1_.criterion_id as criterion27_73_0_,
routingcri1_.location_id aslocation26_73_0_,
routingcri1_.RoutingComponentType as RoutingC1_73_0_
from odp_rulecriteriajoin criteria0_
left outer join odp_routingcomponent as routingcri1_ on criteria0_.CriteriaComponentId=routingcri1_.id
where criteria0_.RoutingRuleId=1 order by odp_routingcomponent .priority asc
It is wrong since not the table alias is used in the order by clause, but the real table name.
Mysql fails with exception that odp_rulecriteriajoin.priority is unknown table.
Changing the query to include "order by criteria0_.priority asc" returns the correct result.
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-5565) Memory leak is possible if changes for audited entities are outside of transaction
by Eugene Goroschenya (JIRA)
Memory leak is possible if changes for audited entities are outside of transaction
----------------------------------------------------------------------------------
Key: HHH-5565
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5565
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.1
Environment: hibernate-core-3.3.1.GA.jar, jboss-envers-1.2.1-hibernate-3.3.jar
Reporter: Eugene Goroschenya
Envers always collects changes for audited objects in global (global per sessionFactory instance) application map (auditConfiguration.auditSyncManager.auditSyncs<Transaction, AuditSync>) even if transaction is inactive.
It leads to memory leak in application if there were changes (insert/update/delete) for versioned objects outside of transaction (transaction.isActive() == false) because in this case transaction is not committed where collected changes for current transaction are removed from global map.
Possible solution is patch Envers to check if transaction is active (AuditEventListener in onPostInsert/onPostUpdate/onPostDeleteonCollectionAction methods) before starting collect changes for audited object.
Skip collecting (to prevent memory leak) if transaction is inactive and log WARN message to indicate problem ("Couldn't create revision for entity ${entityName} because transaction is not active.")
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-5411) Missing value in not updatable column in Envers audit table
by Laurent Grangier (JIRA)
Missing value in not updatable column in Envers audit table
-----------------------------------------------------------
Key: HHH-5411
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5411
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.3.0.GA
Environment: Hibernate 3.4
Reporter: Laurent Grangier
When I update an entity with a property which is updatable=false and that the property is not filled when passing the object to Hibernate, the update is correctly made by Hibernate but Envers fill a null value in the given column in the audit table.
Example :
{code}
public class MyEntity {
private String myString;
@Column(updatable = false)
private Long myLong;
(...)
}
MyEntity entity = new MyEntity();
entity.setMyString("example");
entity.setMyLong(123L);
entityManager.persist(entity);
Long entityId = entity.getId();
(...)
MyEntity entity = new MyEntity();
entity.setId(entityId);
entity.setMyString("new value");
entityManager.persist(entity); // Here Envers miss to fill the column myLong in the audit table !
{code}
In the above example, in the audit table, the value of "myLong" will be "null" but I expected "123" instead.
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-5929) PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe
by Robin Sander (JIRA)
PooledLoOptimizer in conjunction with SequenceStyleGenerator is not thread-safe
-------------------------------------------------------------------------------
Key: HHH-5929
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5929
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.1
Environment: Hibernate 3.6.1, Java 6, Mac OS 10.6.6
Reporter: Robin Sander
The generate method of the PooledLoOptimizer introduced in 3.6.1 is not synchronized in difference to the one in PooledOptimizer and in other Optimizer implementations. The problem is that some IdentifierGenerator implementations have themselve a synchronized generate method (like SequenceHiLoGenerator e.g.) and some don't, like the new SequenceStyleGenerator.
According to the javadoc IdentifierGenerator implementations have to be thread-safe. Now I don't know if there is any agreement among the developers whether this thread-safety is to be achieved in the IdentifierGenerator itself or in the Optimizer most of them delegate to but what I know is that SequenceStyleGenerator in conjunction with PooledLoOptimizer is not thread-safe because neither of them guards against concurrent access in any way.
--
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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-2158) incorrect hql query on one-to-one with property-ref
by Sebastien Cesbron (JIRA)
incorrect hql query on one-to-one with property-ref
----------------------------------------------------
Key: HHH-2158
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2158
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: hibernate 3.2.0.ga with firebird 1.5.3 and jaybird 1.5.5 driver on windows XP
Reporter: Sebastien Cesbron
Attachments: testhib.zip
I have a one-to-one relationship with property-ref between Master and Slave2.
I want to find all Master instances that have a null Slave2 instance associated.
To do so my query is
select master from Master master where master.slave2 is null
The sql generated is
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_ where master0_.oid is null
which seems incorrect. It checks here Master instances with null id (config files are listed below).
If I do my query like this
select master from Master master where master.slave2.oid is null
the generated sql is ok :
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_, Slave2 slave2x1_ where master0_.oid=slave2x1_.myMaster and (slave2x1_.oid is null)
I have attached a small eclipse project that reproduces the problem
This problem may-be related to the one I have submitted as issue HHH-1849
--
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
12 years, 6 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
12 years, 6 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
12 years, 6 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
12 years, 6 months
[Hibernate-JIRA] Created: (HHH-5072) Invalid SQL produced when using FetchMode.SUBSELECT with SQLServerDialect
by kabram (JIRA)
Invalid SQL produced when using FetchMode.SUBSELECT with SQLServerDialect
-------------------------------------------------------------------------
Key: HHH-5072
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5072
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.0-Final
Environment: Hibernate core 3.5, JPA 2.0, SQL Server 2005, JDK 1.6
Reporter: kabram
Priority: Blocker
I have a parent entity with child entities being loaded using SubSelect and eager fetching. I execute a query to retrieve all parents and get the following query which SQL Server 2005 does not support:
select
childtab0_.CONFIG_KEY as CONFIG5_23_1_,
childtab0_.QUALIFIER as QUALIFIER23_1_,
childtab0_.CONFIG_VALUE_ID as CONFIG1_1_,
childtab0_.CONFIG_VALUE_ID as CONFIG1_24_0_,
childtab0_.CONFIG_KEY as CONFIG5_24_0_,
childtab0_.QUALIFIER as QUALIFIER24_0_,
childtab0_.CONFIG_VALUE as CONFIG2_24_0_,
childtab0_.IS_ENCRYPTED as IS3_24_0_,
childtab0_.LIST_ORDER as LIST4_24_0_
from
TEST_CHILD_TABLE childtab0_
where
(childtab0_.CONFIG_KEY, childtab0_.QUALIFIER) in
(select parenttab0_.CONFIG_KEY, parenttab0_.QUALIFIER
from RSS_NEO_CANYON_CONFIG_KEY parenttab0_ )
order by
childtab0_.LIST_ORDER asc
SQL Server does not like the tuple in the where clause.
--
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
12 years, 6 months