join fetching causes objects to be read incorrectly
---------------------------------------------------
Key: HHH-1692
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1692
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: Hibernate 3.1, SQLServer2000
Reporter: Mark Brocato
Priority: Critical
Though it is documented that using outer-join fetching for a collection returns duplicate records in the results of a query, the problem is actually much worse than that. If there are any mapped collections whose elements also contain mapped collections, the results of the query will not only be incorrect, the objects themselves will be incorrect. Each mapped collection may contain repeated elements. The problem compounds recursively. If these objects are then modified and flushed, the result will be a corrupt database! Join fetching as it is currently implemented is extremely dangerous to use and if this functionality is not fixed, join fetching should be disabled for all collection mappings.
A simple example is a tree node which can contain a list of child tree nodes, querying the tree nodes with depth > 1 using join fetching will result in corrupt tree nodes being returned. Though this example uses a recursive hierarchy, the hierarchy need not be recursive to produce the undesired results.
Query:
session.createCriteria(TreeNode.class)
.setFetchMode("children", FetchMode.JOIN)
.setFetchMode("children.children", FetchMode.JOIN)
...
.list();
Mapping:
<hibernate-mapping>
<class
name="TreeNode"
table="TREE_NODES"
>
<id
name="id"
column="id"
type="java.lang.Integer"
>
<generator class="identity"/>
</id>
<list
name="children"
lazy="false"
cascade="none"
>
<key
column="parent_id"
>
</key>
<index
column="idx"
/>
<one-to-many
class="TreeNode"
/>
</list>
</class>
</hibernate-mapping>
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1125?page=comments#action_22830 ]
Cameron Lerch commented on HHH-1125:
------------------------------------
I have provided a patch to fix this, see HHH-530.
> better handling of filter params in HQL to allow filter use on subqueries
> -------------------------------------------------------------------------
>
> Key: HHH-1125
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1125
> Project: Hibernate3
> Type: Improvement
> Components: core
> Reporter: Steve Ebersole
> Assignee: Steve Ebersole
>
>
> Currently in HQL queries, the translator disables inclusion of filters on subqueries. Mainly, this was due to the fact that the parameter binding code gets confused because the parameters end up "out of expected order" (filter parameters are always expected to be the first bind points within the resulting SQL query).
> However, it is definitely possible to have the translator deal with this correctly. This will require changes to JoinProcessor, Loader, QueryLoader, and (possibly) FromElementFactory to make use of the ParameterSpecification stuff currently tracked on HqlSqlWalker.
> Then, we should allow a (SF-scoped) config option as to whether filters should be applied to subqueries (false by default).
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685?page=all ]
John updated HHH-1685:
----------------------
Attachment: hhh1685-example.txt
Added the example as an attachment since the formatting was screwed up in the comment
> DetachedCriteria doesn't create alias on subcriteria
> ----------------------------------------------------
>
> Key: HHH-1685
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685
> Project: Hibernate3
> Type: Bug
> Components: query-criteria
> Versions: 3.1.3
> Reporter: John
> Attachments: hhh1685-example.txt
>
>
> DetachedCriteria has two createCriteria methods:
> public DetachedCriteria createCriteria(String associationPath) throws HibernateException
> public DetachedCriteria createCriteria(String associationPath, String alias) throws HibernateException
> However, the code for both was identical - they called the inner criteria's createCriteria(String) method. The version with the alias did not call the inner's version with the alias. The following patch snipped shows the change:
> public DetachedCriteria createCriteria(String associationPath, String alias)
> throws HibernateException {
> - return new DetachedCriteria( impl, criteria.createCriteria(associationPath) );
> + return new DetachedCriteria( impl, criteria.createCriteria(associationPath, alias) );
> }
> This bug was discovered while trying to link a 2-deep subquery to its parent via aliases. (Surfacing this issue might only be possible with the patch HHH-952 in place - I'm not sure. Seems like a bug regardless, as it definitely fixed my alias reference issue.) I'll get an example posted shortly.
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685?page=comments#action_22827 ]
John commented on HHH-1685:
---------------------------
Okay, here's a representative of the sql I wanted. I need to find some rows with a certain status. I need to limit the results, but I have to process the children grouped by parent, so the row limit has to be on the parent, hence the 'in' subquery. The 'in' subquery has an exists because which parents qualify depends on the status of their other children.
select c.*
from
child c join parent p on c.parent_id = p.id
where
c.status = 'findme'
and p.id in (
select top 50 p.id
from
child c2
join parent p2 on c2.parent_id = p2.id
where
c2.status = 'findme'
and not exists (select * from other_child oc where oc.parent_id = p2.id and oc.status != 'done')
)
This is the Criteria used:
Criteria crit = session.createCriteria(Child.class, "c");
Criteria pCrit = crit.createCriteria("parent", "p");
crit.add(Restrictions.eq(Child.STATUS, 'findme'));
DetachedCriteria inSubq = DetachedCriteria.forClass(Child.class, "c2");
DetachedCriteria inPCrit = inSubq.createCriteria("parent", "p2");
inSubq.add(Restrictions.eq(Child.STATUS, 'findme'));
inPCrit.setProjection( Projections.id() );
pCrit.add( Subqueries.propertyIn(Parent.ID, inSubq) );
DetachedCriteria existsSubq = DetachedCriteria.forClass(OtherChild.class, "oc");
existsSubq.add(Restrictions.ne(OtherChild.STATUS, 'done'));
existsSubq.add( Restrictions.eqProperty("oc.parent.id", "p2.id") ); //didn't work without patch in HHH-1685
existsSubq.setProjection(Projections.id());
inSubq.add( Subqueries.notExists(existsSubq) );
inSubq.setMaxResults(50); //doesn't work - see HHH-912
Without the patch I indicated, the join from the exists query to the in query didn't work because the alias was never registered. Also note that while I fixed this problem, I currently cannot complete this query because maxResults does not work on DetachedCriteria, nor on subqueries at all. See HHH-912 for details.
> DetachedCriteria doesn't create alias on subcriteria
> ----------------------------------------------------
>
> Key: HHH-1685
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1685
> Project: Hibernate3
> Type: Bug
> Components: query-criteria
> Versions: 3.1.3
> Reporter: John
>
>
> DetachedCriteria has two createCriteria methods:
> public DetachedCriteria createCriteria(String associationPath) throws HibernateException
> public DetachedCriteria createCriteria(String associationPath, String alias) throws HibernateException
> However, the code for both was identical - they called the inner criteria's createCriteria(String) method. The version with the alias did not call the inner's version with the alias. The following patch snipped shows the change:
> public DetachedCriteria createCriteria(String associationPath, String alias)
> throws HibernateException {
> - return new DetachedCriteria( impl, criteria.createCriteria(associationPath) );
> + return new DetachedCriteria( impl, criteria.createCriteria(associationPath, alias) );
> }
> This bug was discovered while trying to link a 2-deep subquery to its parent via aliases. (Surfacing this issue might only be possible with the patch HHH-952 in place - I'm not sure. Seems like a bug regardless, as it definitely fixed my alias reference issue.) I'll get an example posted shortly.
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

org.hibernate.util.IdentityMap should be more API-compatible to improve perfomance
----------------------------------------------------------------------------------
Key: HHH-1691
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1691
Project: Hibernate3
Type: Improvement
Components: core
Reporter: Sergey Vladimirov
Priority: Minor
To improve perfomance methods entrySet() entryList() should return back-linked set and list. They should have such set and list precreated along with org.hibernate.util.IdentityMap, and do NOT recreate it on each call.
It is called on commit() and it decrease perfomance for Extended Entity Manager
at java.util.HashMap.addEntry(HashMap.java:754)
at java.util.HashMap.put(HashMap.java:405)
at java.util.HashSet.add(HashSet.java:200)
at org.hibernate.util.IdentityMap.entrySet(IdentityMap.java:177)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:323)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:28)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:988)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:337)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:59)
If there is some reason not to do it, such reason should me specified in java-doc for those methods.
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

unexpected AST node: query -- CASE WHEN THEN subquery
-----------------------------------------------------
Key: HHH-1689
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1689
Project: Hibernate3
Type: Bug
Components: query-sql
Environment: Hibernate 3.x
Oracle 9.2.0
Reporter: Alejandro Torras
Hello,
I got a <<org.hibernate.hql.ast.QuerySyntaxError: unexpected AST node: query [ >> exception with the following query:
FROM
t1 AS vo,
t2 AS vo2
WHERE vo2.indIdiomaSistema = 'S'
AND vo.id.codiIdioma.id = :id_codiIdioma_id
GROUP BY vo.id.codiTipusIdent.id
HAVING COUNT(*) BETWEEN
CASE :estat
WHEN '1' THEN (SELECT COUNT(*) FROM t2 WHERE ind_idioma_sistema = 'S')
ELSE 0 END
AND 4
ORDER BY vo.nomTipusIdent asc
It seems that the THEN clause doesn't expect a query that Oracle 9.2 handles properly.
Regards,
Alejandro Torras.
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-377?page=all ]
Max Rydahl Andersen updated HBX-377:
------------------------------------
Fix Version: 3.2LATER
(was: 3.1.beta5)
will leave it as a known annoyances until next version
> Can't save HQL Scratchpad
> -------------------------
>
> Key: HBX-377
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-377
> Project: Hibernate Tools
> Type: Bug
> Components: consoleconfiguration
> Versions: 3.1alpha5
> Environment: Windows XP, Eclipse 3.1
> Reporter: Dan Bradley
> Priority: Minor
> Fix For: 3.2LATER
>
>
> There is no way to save a non-empty HQL Scratchpad or otherwise mark it non-dirty. To reproduce:
> - Open a scratchpad window, it's non-dirty.
> - Enter anything into it, it's now dirty, as shown by the asterisk in front of the name on its tab.
> - Try to save it, it doesn't save, and its dirty state does not change.
> - Many Eclipse tasks will now ask you to save it before proceeding
> - Try to close it, Eclipse prompts you to save. Say no and the editor closes. But say yes and it also closes also without saving.
> More broadly, I'm not sure about the UI approach. What does it mean to save a scratchpad? Do I have to save it to a file? It's a scratchpad after all, not something I want to keep around. But I do want multiple scratchpads to be available. If I save it and it uses some hidden temporary file, that seems like an abuse of the Eclipse editor window. Maybe the scratchpad should be an Eclipse view that can be embedded in the Console Perspective, and which doesn't track a dirty/non-dirty state?
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-343?page=all ]
Max Rydahl Andersen updated HBX-343:
------------------------------------
Fix Version: 3.2LATER
(was: 3.1.beta5)
must wait to next release (and users should learn to respond ;)
> Add support for class prefix and suffix in DO and DAO generation
> ----------------------------------------------------------------
>
> Key: HBX-343
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-343
> Project: Hibernate Tools
> Type: Improvement
> Components: hbm2java
> Reporter: Adrian Newby
> Assignee: Max Rydahl Andersen
> Priority: Minor
> Fix For: 3.2LATER
> Attachments: HibernateExt-class-prefix-suffix-diff.txt, HibernateExt-hbm-prefix-suffix-diff.txt
>
>
> (Diff will be attcahed to this issue with all code changes)
> Added support for prefixing and suffixing of class names for generated domain and DAO objects. Update includes:
> 1. Extended BasicGeneratorSettingsPage to add UI elements
> 2. Extended ArtifactGenerator to support new features
> 3. Extended POJOExporter to accomodate additional prefix/suffix information
> 4. Updated Velocity templates to incorporate new features
> The only quirky bit of this is that since the domain prefix and suffix are potentially required in both domain AND dao class generation, they are linked to both the Domain and DAO checkboxes in the UI. This leads to a little bit of weird behavior. (Check on DAO and all 4 prefix and suffix fields are enabled. Now, check and uncheck the domain checkbox and you will see the two domain prefix and suffix fields disable. The situation is recoverable by unchecking and rechecking the DAO checkbox.)
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-270?page=all ]
Max Rydahl Andersen updated HBX-270:
------------------------------------
Fix Version: 3.2LATER
Assign To: Marshall Culpepper
Fix Version: (was: 3.1.beta5)
did not make it for this release.
> Code generation ui should be able to be configured to use same exporter with different parameters
> -------------------------------------------------------------------------------------------------
>
> Key: HBX-270
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-270
> Project: Hibernate Tools
> Type: New Feature
> Components: hbm2java
> Versions: 3.0alpha
> Environment: Hibernate tools 3.0 alpha 1
> Reporter: daviddickinson@...
> Assignee: Marshall Culpepper
> Priority: Minor
> Fix For: 3.2LATER
>
>
> The old hbm2java tool could be configured to use 2 renderers, in order to generate an abstract base class, and also an empty concrete class, for each mapping file.
> This was achieved by using something like this in the config.xml passed to the hbm2java tool:
> <codegen>
> <generate prefix="Base" renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer"/>
> <generate renderer="net.sf.hibernate.tool.hbm2java.BasicRenderer">
> <param name="generate-concrete-empty-classes">true</param>
> <param name="baseclass-prefix">Base</param>
> </generate>
> </codegen>
> This cannot yet be done with the current Hibernate 3.0 alpha 1 code-generation wizard.
> It would be really useful if there was either :-
> - some way of specifying an external config.xml file to the wizard, or
> - a means of adding/configuring code renderers and setting their parameters via the wizard UI.
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-625?page=all ]
Max Rydahl Andersen updated HBX-625:
------------------------------------
Fix Version: 3.2LATER
(was: 3.1.beta5)
we have an extension point but does not support the above features yet. consider it experimental until then.
> Exporter extension point
> ------------------------
>
> Key: HBX-625
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-625
> Project: Hibernate Tools
> Type: New Feature
> Components: eclipse
> Reporter: Max Rydahl Andersen
> Assignee: Marshall Culpepper
> Fix For: 3.2LATER
>
>
> Support properties per Exporter
> (Properties button next to list, Add/Remove property list with the properties defined in the extension point)
> Support global properties
> (keep the static list of jdk5 and ejb3 and have an adv properties dialog with Add/remove property which lists all the exporter types in a tree with childnodes for properties defined in the extension point)
> Support adding exporters (similar to hbmtemplate)
--
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.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira