[Hibernate-JIRA] Created: (HHH-2258) Bad SQL Grammer: Implicit join when using r.fooClass.attributes[?]=?
by Darryl Miles (JIRA)
Bad SQL Grammer: Implicit join when using r.fooClass.attributes[?]=?
--------------------------------------------------------------------
Key: HHH-2258
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2258
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Environment: MySQL server this has been tested with.
Reporter: Darryl Miles
Priority: Critical
Attachments: test_joinedmapfilter.zip
Please find this test case atteched to demonstrate the bug, maybe you can add to the hibernate distribution for future testing and piece of mind for me.
The error:
Testsuite: org.hibernate.test.joinedmapfilter.JoinedMapFilterTest
Tests run: 1, Failures: 0, Errors: 1, Time elapsed: 0.498 sec
Testcase: testJoinedMapFilter took 0.495 sec
Caused an ERROR
could not execute query
org.hibernate.exception.SQLGrammarException: could not execute query
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
at org.hibernate.loader.Loader.doList(Loader.java:2147)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2028)
at org.hibernate.loader.Loader.list(Loader.java:2023)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:393)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.test.joinedmapfilter.JoinedMapFilterTest.testJoinedMapFilter(JoinedMapFilterTest.java:116)
at org.hibernate.test.TestCase.runTest(TestCase.java:250)
at org.hibernate.test.TestCase.runBare(TestCase.java:316)
Caused by: java.sql.SQLException: Unknown table 'productdet1_' in where clause
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2928)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1571)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1666)
at com.mysql.jdbc.Connection.execSQL(Connection.java:2994)
at com.mysql.jdbc.PreparedStatement.executeInternal(PreparedStatement.java:936)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1030)
at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186)
at org.hibernate.loader.Loader.getResultSet(Loader.java:1668)
at org.hibernate.loader.Loader.doQuery(Loader.java:662)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2144)
... 25 more
SELECT r FROM com.company.Toplevel AS r WHERE r.toplevel=? AND rec.productDetail.attributes[?]=?
Also my recent post: http://forum.hibernate.org/viewtopic.php?t=966374&start=0&postdays=0&post...
This testcase has been tested with 3.1.3 and 3.2.0-ga.
2nd problem:
There is also another situation in the testcase which I found through serendipity which causes a NPE inside hibernate because I misspelled "r" as "rec". Check out the commented out section and swap over the createQuery() lines to demonstrate that NPE.
--
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
16 years
[Hibernate-JIRA] Commented: (HHH-1936) IdentityGenerator doesn't support BigInteger as a valid identity type.
by Cailie Crane (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936?page=c... ]
Cailie Crane commented on HHH-1936:
-----------------------------------
Would you please consider removing Sybase 12.05 from the Environment field?
We are using MySQL 5 and just switched to Hibernate JPA from Toplink JPA.
We are affected by this bug because most of our auto-generated Ids are of type BigInteger.
> IdentityGenerator doesn't support BigInteger as a valid identity type.
> ----------------------------------------------------------------------
>
> Key: HHH-1936
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1936
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.0.5
> Environment: Hibernate 3.0.5, Sybase 12.05, Window/ Unix
> Reporter: Leonid Shtivelman
>
> Identity generator strategy doesn't support BigInteger as a valid id type. This causes problem with Sybase which requires identity column to be numeric. It would seem an obvious way to get around this problem is to set column mapping to long in hibernate xml and the actual java object. This will solve obvious problem of creating identity, but will cause performance problem on selection. In order for Sybase to use index for parameter query the variable type of the parameter and column index type has to be the same. If ones maps column type to Long, Hibernate will use JDBC method setLong(long) to set value in the prepared statement. This will cause mismatch between parameter type and column index type, and Sybase will not use index to locate index. As you can see this is a big problem for anyone that is using identity columns Sybase and Hibernate
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3062) Incompleted Collection Returned from Joined Fetch
by Tony Lin (JIRA)
Incompleted Collection Returned from Joined Fetch
-------------------------------------------------
Key: HHH-3062
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3062
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5
Environment: Windows XP SP2, JDK 1.6_03, MySQL 5, Toncat 5.5.25
Reporter: Tony Lin
Attachments: subsets.sql
Executing the following query:
select subset from com.alphait.domain.snomed.object.SubsetImpl as subset join fetch subset.members as members left join fetch members.parent
The members returned after the first subset are not complete, all but the first member are missing.
The classes are attached in HHH-3056. The test data is in the attached file, please load it to a mysql database.
After investigation, the problem seems be in Loader.java's sequentialLoad method:
try {
do {
Object loaded = getRowFromResultSet(
resultSet,
session,
queryParameters,
getLockModes( queryParameters.getLockModes() ),
null,
hydratedObjects,
loadedKeys,
returnProxies
);
if ( result == null ) {
result = loaded;
}
}
while ( keyToRead.equals( loadedKeys[0] ) && resultSet.next() );
}
catch ( SQLException sqle ) {
throw JDBCExceptionHelper.convert(
factory.getSQLExceptionConverter(),
sqle,
"could not perform sequential read of results (forward)",
getSQLString()
);
}
initializeEntitiesAndCollections(
hydratedObjects,
resultSet,
session,
queryParameters.isReadOnly()
);
session.getPersistenceContext().initializeNonLazyCollections();
return result;
It will fetch the next subset also, but only the first member, and the member's parent. These three are hydrated, and resolved when initializeEntitiesAndCollections is called.
This makes the members collection to be freezed, and no member can be added.
We put the following:
key = getKeyFromResultSet(
0,
persisters[0],
null,
resultSet,
session
);
if (!keyToRead.equals(key)) { // we are done, no moving forward
break;
}
before calling getRowFromResultSet(). This temporarily solved the problem for us.
Also this kind of query cannot have order by containing only the members' properties as it will return rows not ordered by Subset's ID. I think the HQL query parser should not permit this.
--
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
16 years
[Hibernate-JIRA] Created: (HHH-3582) Conceptual Queries extension for HSQL:Queries are too sensitive to model changes
by Francisco Peredo (JIRA)
Conceptual Queries extension for HSQL:Queries are too sensitive to model changes
--------------------------------------------------------------------------------
Key: HHH-3582
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3582
Project: Hibernate Core
Issue Type: New Feature
Components: query-criteria, query-hql
Reporter: Francisco Peredo
When a query is written in JPAQL or HSQL, it still depends to much on the domain model (I think HSQL could be extended to support Conceptual Queries).
For example, lets say you want to:
Find each white cat that lives in a house with doors made of wood
A cat is of one color, it lives in one house, a house can have 1 door and the door can be made of 1 material
So, the query in HSQL looks like this:
select c from Cat c where c.color="white" and c.house.door.material.name = "wood"
But then, lets say our customer changes the requirements:
Find each white cat that lives in a house with doors made of wood
A cat is of one color, it lives in many houses, a each house has many doors and the door is made of one or more materials (for example half glass, half wood)
Since our relationships are now @OneToMany so we write their names in plural, and we are newbies in HSQL we try doing this (and it, of course does not work):
select c from Cat c Cat c where c.color="white" and c.houses.doors.materials.name = "wood"
Now, we can of course solve this problem using subqueries and the exists keyword, but that makes the resulting query way more complex, and even if the above worked, it still is a different query, but, in our english example, the query didn't change:
Find each white cat that lives in a house with doors made of wood
So, why we can not write in HSQL something like:
select c from Cat c where c with color= "white" and lives in House has Doors made of Material with name = "wood"
That way the query wouldn't have to change even if the multiplicity of the relationships changed. Of course now the question is, from where do I get the "with","lives in", "has", "made of" and "with" well, simple:
The with operator is available for each non @Entity member of the class (for strings, integers, etc).
For relationships with other entities we just add the conceptual name of the relationship name as an attribute in the @OneToMany or @ManyToOne annotations:
Example:
public class Cat{
@Column
private String color;
@OneToMany(mappedBy="cat", conceptualName="lives in ")
private Set<House> houses;
}
What do you think?
--
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
16 years