[hibernate-issues] [Hibernate-JIRA] Commented: (HHH-2159) Query that previously worked in 3.2.0CR2 does not work anymore

[Owen Taylor (JIRA)]

    [ http://opensource.atlassian.com/projects/hibernate/browse/HHH-2159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_27283 ] 

Owen Taylor commented on HHH-2159:
----------------------------------

I think this problem is actually pretty simple... it has nothing to do with cast() or <element>.class, etc. It just takes a 
fairly complex select expression to trigger it.

The problem is the call to FromClause.addDuplicateAlias in DotNode.dereferenceEntityJoin(). In the case where we 
have a non-duplicate path expression, classAlias != null is checked in FromClause.registerFromElement().
But when we have a duplicate element, we just go ahead and stuff an entry into the hash map even though the
classAlias is null.

This will be quite common. But most times when it happens, it will be harmless, because we never get to a
call to findIntendedAliasFromElementBasedOnCrazyJPARRequirements.

Most of the "this works" / "this doesn't work" comparisons above are about whether we trigger the NPE, not
about whether we add the null to the hash map.

If a good test case can't be extracted from the above, I'd suggest that a reliable way of triggering the problem
should be something like:

  SELECT a FROM A a 
   WHERE EXISTS (select * from B b WHERE b.c.i = 1 OR b.c.j = 2 OR b.c.a = a)

If I understand the code right, the first two paths above will cause a NULL to be inserted into the hash map,
and the third check will cause a NPE because it needs to do the CrazyJPARRequirements() check *before*
it goes to the parent from clause and finds 'a'.

But the patch I'm going to attach in a bit should be obviously correct by inspection.


> Query that previously worked in 3.2.0CR2 does not  work anymore
> ---------------------------------------------------------------
>
>                 Key: HHH-2159
>                 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2159
>             Project: Hibernate3
>          Issue Type: Bug
>    Affects Versions: 3.2.0.ga
>         Environment: hibernate 3.2.0GA, PostgreSQL 8.1.4 (using build 407 of the JDBC driver).  JDK 1.5.0_06, JBoss 4.0.4GA, Operating system is Fedora Core 5
>            Reporter: Andy Dale
>         Attachments: FromClause.java, FromClause.java.diff, hibernate_testcase.tar.gz, HibernateTestcase.tar.gz, OrignalTest.tar.gz
>
>
> First off i do not know if this bug belongs to the Hibernate3(core) or Hibernate EntityManger branch, but have entered it against core because that is where the exception occurs (in org.hibernate.hql.ast.tree.FromClause.findIntendedAliasedFromElementBasedOnCrazyJPARequirements).
> I have a relativley simple entity setup up to test a proof of concept.  Persisting the data to the database is not a problem in the new version 3.2.0.GA, but the problems occurs when trying to perform a query on the persisted data, the very same query works with 3.2.0CR2 but gives a nullPointException in 3.2.0GA.
> I have attached the java source for the entities + session bean (in hibernate_testcase.tar.gz/entities file) and the java class (in hibernate_testcase.tar.gz/service file) that is used to persist and query the data, and because this was only meant to be a proof of concept i have also included the .ear archive as apart from the entity definitions and session bean the only other thing it contains is a JBoss .sar archive which calls the static persist and query methods in the session bean (service test.testcase).  Please note to use the .ear archive you need a datasource called Postgres_Test

-- 
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