[Hibernate-JIRA] Created: (HHH-4630) Criteria join on composite identifier generates wrong alias, SQL error
by Chris Wilson (JIRA)
Criteria join on composite identifier generates wrong alias, SQL error
----------------------------------------------------------------------
Key: HHH-4630
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4630
Project: Hibernate Core
Issue Type: Patch
Components: core
Affects Versions: 3.5
Environment: Hibernate trunk from 2009-11-30, Ubuntu 8.04, Sun Java 1.6.0-17, MySQL 5.0.51a-3ubuntu5.4
Reporter: Chris Wilson
Attachments: hibernate-invalid-alias-generation.patch
Hibernate generates the wrong alias on a Criteria query involving a join
on a composite identifier. For example, in the test below without the fix
to JoinWalker, it generates this SQL:
select
this_.role_code as role1_0_1_,
this_.is_deleted as is2_0_1_,
this_.record_version as record3_0_1_,
complexjoi3_.code as code1_0_,
complexjoi3_.is_deleted as is2_1_0_,
complexjoi3_.record_version as record3_1_0_
from
list_action_roles this_
left outer join
roles complexjoi3_
on this_.role_code=complexjoi3_.code
where
this_.is_deleted=?
and complexjoi1_.is_deleted=?
Which results in this error from the SQL server:
Unknown column 'complexjoi1_.is_deleted' in 'where clause'
Analysis of the problem:
The entity persister class with the composite identifier has a fake
property for it, called "_identifierMapper" (see HbmBinder.bindCompositeId()
and similarly in Annotations). This property name ends up in the path
used by JoinWalker.walkEntityTree() when it calls walkComponentTree().
However that path is used by CriteriaJoinWalker.generateTableAlias()
to look up the correct criteria (and hence the alias) from the
translator, a CriteriaQueryTranslator.
The alias was created in CriteriaQueryTranslator.createCriteriaSQLAliasMap
for a Criteria without this extra _identifierMapper path component.
So when CriteriaJoinWalker tries to use the path with _identifierMapper
to look up the criteria to find the correct alias to use, in
generateTableAlias(), it doesn't find one, so it generates a new alias.
That new alias no longer matches the one that will be rendered out in
the WHERE clause, so the WHERE clause will refer to table names using
aliases that are not used anywhere else in the query, and the SQL server
will fail to parse the statement.
The solution appears to be to exclude "_identifierMapper" components in
the alias path when building it. I don't know what other implications
that might have, but it seems like an implementation nastiness that
shouldn't be exposed.
Patch attached.
--
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: (HSEARCH-210) Support hbm xml mapping!
by Mark Stewart (JIRA)
Support hbm xml mapping!
------------------------
Key: HSEARCH-210
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-210
Project: Hibernate Search
Issue Type: Bug
Components: mapping
Affects Versions: 3.0.1.GA
Environment: All.
Reporter: Mark Stewart
I like annotations as much as the next guy but it's a complete non-starter for our business (and, I suspect, plenty of others) to add full text search to our existing apps via Hibernate Search if it means we must convert all our existing hbm.xml configurations into annotations. The regression testing alone would kill us.
The Hibernate project has always been supremely pragmatic which is why I've filed this as a bug rather than a feature request. I don't think Hibernate would have been half as popular if it didn't support things like direct SQL and reverse engineering tools. I think Search would see a big boost if it could be easily added to existing applications.
Please consider adding the needed syntax for xml mapping. At the very least an entry in the FAQ that explains the lacking is needed.
--
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-3031) Include "FOR READ ONLY" hint in non-locking DB2 statements
by Steve Finch (JIRA)
Include "FOR READ ONLY" hint in non-locking DB2 statements
----------------------------------------------------------
Key: HHH-3031
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3031
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.2.5
Environment: 3.2.5, DB2/UDB 8.1+
Reporter: Steve Finch
As per the DB2 documentation:
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.i...
The FOR READ ONLY clause indicates that the result table is read-only and therefore the cursor cannot be referred to in Positioned UPDATE and DELETE statements. FOR FETCH ONLY has the same meaning.
For result tables in which updates and deletes are allowed, specifying FOR READ ONLY (or FOR FETCH ONLY) can possibly improve the performance of FETCH operations by allowing the database manager to do blocking. For example, in programs that contain dynamic SQL statements without the FOR READ ONLY or ORDER BY clause, the database manager might open cursors as if the FOR UPDATE clause were specified. It is recommended, therefore, that the FOR READ ONLY clause be used to improve performance, except in cases where queries will be used in positioned UPDATE or DELETE statements.
A read-only result table must not be referred to in a Positioned UPDATE or DELETE statement, whether it is read-only by nature or specified as FOR READ ONLY (FOR FETCH ONLY).
The aforementioned improvement can be achieved by applying "FOR READ ONLY" when other locking hints are not specified.
Patch to be uploaded soon.
--
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-4975) ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property
by Christian Fritschi (JIRA)
ManyToOne and referencedColumnName and MappedSuperclass (2 Levels) => org.hibernate.AnnotationException: referencedColumnNames ... not mapped to a single property
------------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-4975
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4975
Project: Hibernate Core
Issue Type: Bug
Components: annotations
Affects Versions: 3.3.2
Environment: Hibernate version 3.3.2.GA, HSQLDB 1.8.0.10
Reporter: Christian Fritschi
Priority: Critical
Attachments: startTestDb.rar, ukMapping.rar, UkMappingTest.java
Level 1 (superClass)
-------
@MappedSuperclass
public abstract class AbstractMasterUk ...
@Id
private int id;
....
@Column(name="MASTER_ID", nullable = false, length=50)
private String masterId;
Level 2 (superClass)
-------
@Entity
@Inheritance(strategy=InheritanceType.SINGLE_TABLE)
@Table(name="MASTER_UK")
@DiscriminatorColumn(name="DOMAIN", discriminatorType=DiscriminatorType.STRING)
public class MasterUkBase extends AbstractMasterUk ....
Parent-Class
------------
@Entity
@org.hibernate.annotations.Entity(mutable = false)
@DiscriminatorValue(MasterUk1.DOMAIN)
public class MasterUk1 extends MasterUkBase ...
Child-Class
-----------
@Entity
@Table(name="DETAIL_UK")
public class DetailUk implements Serializable {
@Id
private int id;
@ManyToOne(optional=false)
@JoinColumn(name="MASTER", nullable=true, referencedColumnName="MASTER_ID")
private MasterUk1 master;
Result:
org.hibernate.AnnotationException: referencedColumnNames(MASTER_ID) of annotations.playground.delta.ukMapping.DetailUk.master referencing annotations.playground.delta.ukMapping.MasterUk1 not mapped to a single property
at org.hibernate.cfg.BinderHelper.createSyntheticPropertyReference(BinderHelper.java:180)
at org.hibernate.cfg.ToOneFkSecondPass.doSecondPass(ToOneFkSecondPass.java:88)
at org.hibernate.cfg.AnnotationConfiguration.processEndOfQueue(AnnotationConfiguration.java:456)
at org.hibernate.cfg.AnnotationConfiguration.processFkSecondPassInOrder(AnnotationConfiguration.java:438)
at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:309)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1333)
at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:867)
.....
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3495) CollectionAction instances can consume considerable memory in large transactions unnecessarily
by Tim Downey (JIRA)
CollectionAction instances can consume considerable memory in large transactions unnecessarily
----------------------------------------------------------------------------------------------
Key: HHH-3495
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3495
Project: Hibernate Core
Issue Type: Improvement
Reporter: Tim Downey
Attachments: CollectionActionPatch.zip
Hi,
We're doing some fairly heavy duty batch processing using Hibernate 3.3.1. In doing so, we're basically paging over large chunks of entities where we flush and clear the session around pages. We do not commit between pages. We may be processing hundreds of thousands of entities over pages of ten to twenty thousand each.
We're clearing the session around pages in attempt to free up memory that is no longer necessary. We have found that subtypes of CollectionAction get added to a list of Executable in the ActionQueue when there are collection changes processed. These CollectionActions are held until transaction complete and are not released on flush or clear of the session.
Furthermore, the CollectionAction instances hold references to those collections that have changed even after the entities have been evicted from the session. In our case, this was causing Hibernation to hold on to several hundred MB of RAM until transaction commit.
I've supplied a small patch that doesn't require the CollectionAction to hang on to the entities themselves until the transaction boundary. We're showing considerably improvement in memory utilization as a result. I'm hoping that you consider this patch for inclusion in a future release.
The change was basically to change the ActionQueue's list of Executables used in after transaction completion, to a separate type, AfterTransactionCompletionExecutable. This new type allows some decoupling in the other subclasses of Executable to hold references to fewer resources and save considerable memory when the transaction sizes are quite large.
Regards,
Tim
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-2169) L2 Cache and Long transactions Memory Leak : OutOfMemoryException
by Sami Dalouche (JIRA)
L2 Cache and Long transactions Memory Leak : OutOfMemoryException
-----------------------------------------------------------------
Key: HHH-2169
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2169
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: [b]Hibernate version:[/b]
Hibernate Entity Manager 3.2.0, with Hibernate Core 3.2.0 and Hibernate Annotations 3.2.0
[b]Mapping documents:[/b]
Annotations
[b]Full stack trace of any exception that occurs:[/b]
Memory Heap Exception
[b]Name and version of the database you are using:[/b]
PosgreSQL 8.1
Reporter: Sami Dalouche
Summary
---------
When enabling L2 Cache (with either OScache and EhCache, both with a limitation on the max #of instances, so the problem shouldn't come from the cache manager), Hibernate cannot have long running transactions, otherwise, it results in a Memory Heap Exception...
The problem does NOT happen if the L2 Cache is disabled !
Details
----------
- Configure the code to run in ONE transaction
- Have a huge loop that inserts 2 million entries that are cacheable (@Cache(usage = CacheConcurrencyStrategy.NONSTRICT_READ_WRITE))
- flush() and clear() every 1000 entries, to periodically flush the cache
=> None of the entries are garbage collected.
=> Using a profiler, it is possible to trace the owning objects of my domain classes to :
- org.hibernate.action.EntityInsertAction ("instance" variable)
- array / List (variable elementData)
- variable "executions" in object .. class org.hibernate.engine.ActionQueue
Remarks :
- If the Query Cache is disabled, and the objects being inserted are NOT cacheable (no @Cache annotation), there is no problem
- If the Query Cache is enabled, then, no matter whether the objects being inserted are cacheable or not, The entries are never garbage collected, and I get an OutOfMemoryException. (I see NO relationship between the Query Cache and my objects. I never query the objects, only save them !!)
--
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, 6 months