[Hibernate-JIRA] Created: (HHH-5804) Left outer join has extra incorrect join components
by YU (JIRA)
Left outer join has extra incorrect join components
---------------------------------------------------
Key: HHH-5804
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5804
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0
Environment: Hibernate 3.6.0 final, oracle, mysql etc.
Reporter: YU
Hibernate 3.3.2 GA was used by our application. After upgrade to hibernate 3.6.0 final, our application was broken. After turned on sql debug, we found that the same HQL query had generated different native sql queries by hibernate 3.6 and 3.3.2. The problem has been verified on Oracle and MySql. It seems some extra unnecessary join components were added to native query by 3.6. Here is an example.
HQL query:
select ResolveActionResult.sysId , ResolveActionResult.sysId , ResolveActionResult.UTimestamp , ResolveActionResult.task.UName , ResolveActionResult.task.sysId , ResolveActionResult.UCompletion , ResolveActionResult.UCondition , ResolveActionResult.USeverity , ResolveActionResult.USummary , ResolveActionResult.process.UNumber , ResolveActionResult.process.sysId , ResolveActionResult.executeRequest.UNumber , ResolveActionResult.executeRequest.sysId , ResolveActionResult.UDuration , ResolveActionResult.UAddress , ResolveActionResult.target.UName , ResolveActionResult.UDetail , ResolveActionResult.executeResult.UCommand , ResolveActionResult.executeResult.UReturncode from com.resolve.persistence.model.ResolveActionResult ResolveActionResult left join ResolveActionResult.task left join ResolveActionResult.process left join ResolveActionResult.executeRequest left join ResolveActionResult.target left join ResolveActionResult.executeResult left join ResolveActionResult.problem where ResolveActionResult.sysId in ( '8a81838b2d09d253012d09d8d20903e0') order by ResolveActionResult.UTimestamp desc
Native SQL created by hibernate 3.3.2 from above HQL:
select
resolveact0_.sys_id as col_0_0_,
resolveact0_.sys_id as col_1_0_,
resolveact0_.u_timestamp as col_2_0_,
resolveact1_.u_name as col_3_0_,
resolveact0_.u_actiontask as col_4_0_,
resolveact0_.u_completion as col_5_0_,
resolveact0_.u_condition as col_6_0_,
resolveact0_.u_severity as col_7_0_,
resolveact0_.u_summary as col_8_0_,
resolvepro2_.u_number as col_9_0_,
resolveact0_.u_process as col_10_0_,
resolveexe3_.u_number as col_11_0_,
resolveact0_.u_execute_request as col_12_0_,
resolveact0_.u_duration as col_13_0_,
resolveact0_.u_address as col_14_0_,
resolvetar4_.u_name as col_15_0_,
resolveact0_.u_detail as col_16_0_,
resolveexe5_.u_command as col_17_0_,
resolveexe5_.u_returncode as col_18_0_
from
resolve3.resolve_action_result resolveact0_
left outer join
resolve3.resolve_action_task resolveact1_
on resolveact0_.u_actiontask=resolveact1_.sys_id
left outer join
resolve3.resolve_process_request resolvepro2_
on resolveact0_.u_process=resolvepro2_.sys_id
left outer join
resolve3.resolve_execute_request resolveexe3_
on resolveact0_.u_execute_request=resolveexe3_.sys_id
left outer join
resolve3.resolve_target resolvetar4_
on resolveact0_.u_target=resolvetar4_.sys_id
left outer join
resolve3.resolve_execute_result resolveexe5_
on resolveact0_.u_execute_result=resolveexe5_.sys_id
left outer join
resolve3.worksheet worksheet6_
on resolveact0_.u_problem=worksheet6_.sys_id
where
resolveact0_.sys_id in (
'8a81838b2d09d253012d09d8d20903e0'
)
Native query created by Hibernate 3.6:
select
resolveact0_.sys_id as col_0_0_,
resolveact0_.sys_id as col_1_0_,
resolveact0_.u_timestamp as col_2_0_,
resolveact7_.u_name as col_3_0_,
resolveact0_.u_actiontask as col_4_0_,
resolveact0_.u_completion as col_5_0_,
resolveact0_.u_condition as col_6_0_,
resolveact0_.u_severity as col_7_0_,
resolveact0_.u_summary as col_8_0_,
resolvepro8_.u_number as col_9_0_,
resolveact0_.u_process as col_10_0_,
resolveexe9_.u_number as col_11_0_,
resolveact0_.u_execute_request as col_12_0_,
resolveact0_.u_duration as col_13_0_,
resolveact0_.u_address as col_14_0_,
resolvetar10_.u_name as col_15_0_,
resolveact0_.u_detail as col_16_0_,
resolveexe11_.u_command as col_17_0_,
resolveexe11_.u_returncode as col_18_0_
from
resolve3.resolve_action_result resolveact0_
left outer join
resolve3.resolve_action_task resolveact1_
on resolveact0_.u_actiontask=resolveact1_.sys_id
left outer join
resolve3.resolve_process_request resolvepro2_
on resolveact0_.u_process=resolvepro2_.sys_id
left outer join
resolve3.resolve_execute_request resolveexe3_
on resolveact0_.u_execute_request=resolveexe3_.sys_id
left outer join
resolve3.resolve_target resolvetar4_
on resolveact0_.u_target=resolvetar4_.sys_id
left outer join
resolve3.resolve_execute_result resolveexe5_
on resolveact0_.u_execute_result=resolveexe5_.sys_id
left outer join
resolve3.worksheet worksheet6_
on resolveact0_.u_problem=worksheet6_.sys_id,
where
resolveact0_.u_actiontask=resolveact7_.sys_id
and resolveact0_.u_process=resolvepro8_.sys_id
and resolveact0_.u_execute_request=resolveexe9_.sys_id
and resolveact0_.u_target=resolvetar10_.sys_id
and resolveact0_.u_execute_result=resolveexe11_.sys_id
and (
resolveact0_.sys_id in (
'8a81838b2d09d253012d09d8d20903e0'
)
)
order by
resolveact0_.u_timestamp desc
Obviously, Hibernate 3.6 generated wrong sql because extra query tables and where conditions were added in generated query such as
resolve3.resolve_action_task resolveact7_,
resolve3.resolve_process_request resolvepro8_,
resolve3.resolve_execute_request resolveexe9_,
resolve3.resolve_target resolvetar10_,
resolve3.resolve_execute_result resolveexe11_
resolveact0_.u_actiontask=resolveact7_.sys_id
and resolveact0_.u_process=resolvepro8_.sys_id
and resolveact0_.u_execute_request=resolveexe9_.sys_id
and resolveact0_.u_target=resolvetar10_.sys_id
and resolveact0_.u_execute_result=resolveexe11_.sys_id
I searched Hibernate forums, but not able to find anything yet. Does anybody know anything about this issue? Thanks a lot.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5805) Allow unmodified objects in session to be garbage collected using weak references
by Archie Cobbs (JIRA)
Allow unmodified objects in session to be garbage collected using weak references
---------------------------------------------------------------------------------
Key: HHH-5805
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5805
Project: Hibernate Core
Issue Type: New Feature
Components: core
Affects Versions: 3.6.0
Reporter: Archie Cobbs
Suggestion for a new feature.
Add a new setting that would configure Hibernate to only weakly reference unmodified objects in the session. Once an object in the session is modified, it would of course need to be strongly referenced. However, after that object's modifications had been persisted (e.g., via a {{flush()}} operation), that object could revert to being weakly referenced again.
This would allow unmodified objects that are no longer referenced by the application to be garbage collected. This would in turn allow an unbounded number of such objects to flow through the persistence context over time, enabling operations that load an arbitrarily large set of objects into one session. Currently this is not possible due to the eventual {{OutOfMemoryError}} you will get if you do this.
The current workaround is to use {{evict()}}, but this is inconvenient and tedious to get right (that is, it's hard to know if you've truly evicted everything or if you've only made the memory leak smaller), especially as the graph of objects loaded into the session gets more complicated. This feature would provide an easy and robust way to eliminate the {{OutOfMemoryError}} problem.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5802) DiscriminatorOptions should not add sql clause
by Marc Schipperheyn (JIRA)
DiscriminatorOptions should not add sql clause
----------------------------------------------
Key: HHH-5802
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5802
Project: Hibernate Core
Issue Type: Improvement
Affects Versions: 3.6.0
Reporter: Marc Schipperheyn
Priority: Minor
@DiscriminatorOptions(force=true)
makes sure discriminator values are processed in cases of table per class hierarchy.
it also leads to sql statement additions such as
where this_.DTYPE in ('STD', 'EVT', 'HDY', 'CAR', 'HSE', 'OFF', 'JOB', 'RST', 'TKE', 'SPL')
since DTYPE is not a nullable field, this is superfluous, all records are loaded anyway without the this qualifier, and may also lead to performance degradation on the database side.
I would suggest optimizing the query generator in order to preven this occurring
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5791) nullability of property is checked even if hibernate.check_nullability is set to false
by Paweł Kępka (JIRA)
nullability of property is checked even if hibernate.check_nullability is set to false
--------------------------------------------------------------------------------------
Key: HHH-5791
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5791
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.0
Environment: Hibernate 3.6.0-Final, MySQL
Reporter: Paweł Kępka
In our application we use a subclass of org.hibernate.cfg.beanvalidation.BeanValidationEventListener which integrates with Spring for entity validation.
In order to wire our class we use following configuration:
hibernate.ejb.event.pre-update=com.acme.SpringBeanValidationEventListener
hibernate.ejb.event.pre-insert=com.acme.SpringBeanValidationEventListener
javax.persistence.validation.mode=none
hibernate.check_nullability=false
But this stopped to work when we tried to switch from Hibernate 3.5.3 to 3.6.0.
When we try to merge an entity which has a null property with @NotNull annotation and nullable set to false we get:
java.lang.NullPointerException: null entities are not supported by org.hibernate.event.def.EventCache
at org.hibernate.event.def.EventCache.containsKey(EventCache.java:80)
at org.hibernate.event.def.DefaultMergeEventListener.mergeTransientEntity(DefaultMergeEventListener.java:361)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsTransient(DefaultMergeEventListener.java:303)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:258)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:84)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:867)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:851)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:855)
at org.hibernate.ejb.AbstractEntityManagerImpl.merge(AbstractEntityManagerImpl.java:686)
instead of ConstraintViolationException. Setting nullable to true resolves the problem but it is temporary solution only.
The whole issues might to be related to HHH-5437.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5736) Problem with "not" function of CriteriaBuilder
by Vyacheslav Dimitrov (JIRA)
Problem with "not" function of CriteriaBuilder
----------------------------------------------
Key: HHH-5736
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5736
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.6.0
Reporter: Vyacheslav Dimitrov
Let us suppose that we have entity "Floor" with property of "number".
Then we want to create query with the help of Criteria API: we want to get all floors and exclude floors with number of 2 and 3. Let us suppose that our code is:
CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery<Tuple> cr = builder.createTupleQuery();
Root<Floor> root = cr.from(Floor.class);
cr.multiselect(root);
Predicate p1 = builder.equal(root.get("number"), new Integer(2));
Predicate p2 = builder.equal(root.get("number"), new Integer(3));
cr.where(builder.not(builder.or(p1, p2)));
So we get query:
[java] Hibernate:
[java] select
[java] floor0_.beanId as beanId0_,
[java] floor0_.building_beanId as building3_1_,
[java] floor0_.number as number1_
[java] from
[java] Floor floor0_
[java] where
[java] floor0_.number=2
[java] or floor0_.number=3
This query is wrong. Function "not" doesn't work.
But for query "get all floors and exlclude floor with number 2" this code works:
CriteriaBuilder builder = em.getCriteriaBuilder();
CriteriaQuery<Tuple> cr = builder.createTupleQuery();
Root<ru.petrsu.nest.son.Floor> root = cr.from(ru.petrsu.nest.son.Floor.class);
cr.multiselect(root);
Predicate p = builder.equal(root.get("number"), new Integer(2));
cr.where(builder.not(p));
We get correct query:
[java] Hibernate:
[java] select
[java] floor0_.beanId as beanId0_,
[java] floor0_.building_beanId as building3_1_,
[java] floor0_.number as number1_
[java] from
[java] Floor floor0_
[java] where
[java] floor0_.number<>3
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-5136) map-key-column is broken
by Harald Wellmann (JIRA)
map-key-column is broken
------------------------
Key: HHH-5136
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5136
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 3.5.1
Environment: Hibernate 3.5.1, PostgreSQL 8.4.3
Reporter: Harald Wellmann
Priority: Critical
I have an entity with a Map<String, Embeddable> with unexpected behaviour. The problem is that annotation mappings and the equivalent XML mappings yield different results. (For brevity, I'm leaving out the getters and setters and the SQL constraints in the following examples.)
Here is my Embeddable:
{code:java}
@Embeddable
public class LocalizedString
{
private String language;
private String text;
}
{code}
And this is the containing entity:
{code:java}
@Entity
public class Amenity
{
@Id
@Column(name = "amenity_id")
@GeneratedValue
private long id;
@ElementCollection
@CollectionTable(name = "amenity_name", joinColumns = @JoinColumn(name = "amenity_id"))
@MapKeyColumn(name = "language_map_key")
private Map<String, LocalizedString> names = new HashMap<String, LocalizedString>();
}
{code}
Hibernate generates the following collection table:
{code:sql}
CREATE TABLE amenity_name
(
amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255),
language_map_key character varying(255) NOT NULL
)
{code}
Now when replacing the annotations by the following XML mapping
{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<entity-mappings version="2.0"
xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd">
<entity class="Amenity">
<attributes>
<id name="id">
<column name="amenity_id"/>
<generated-value />
</id>
<element-collection name="names">
<map-key-column name="language_map_key" />
<collection-table name="amenity_name">
<join-column name="amenity_id" referenced-column-name="amenity_id"/>
</collection-table>
</element-collection>
</attributes>
</entity>
<embeddable class="LocalizedString">
<attributes>
<basic name="language"></basic>
<basic name="text"></basic>
</attributes>
</embeddable>
</entity-mappings>
{code}
the generated SQL looks like this:
{code:sql}
CREATE TABLE amenity_names
(
amenity_amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255),
names_key character varying(255) NOT NULL
)
{code}
It seems that the map-key-column and collection-table settings are simply ignored.
Another question: The column language_map_key is actually redundant, I would like to use the language column as map key instead. The JPA 2.0 spec is a bit vague on this case. When the map value is an entity, @MapKey can be used to select a property of the entity value as map key, but it is not clear to me whether the spec supports supressing the separate key column when the map value is an embeddable.
I tried using @MapKeyColumn(name="language"), but then Hibernate complained about a duplicate column.
Eclipselink (the version contained in Glassfish v3) accepts this usage and suppresses the duplicate column, i.e. the join table has the form
{code:sql}
CREATE TABLE amenity_name
(
amenity_id bigint NOT NULL,
"language" character varying(255),
"text" character varying(255)
)
{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, 5 months