[Hibernate-JIRA] Created: (HHH-2048) Incomplete MappingException at org.hibernate.mapping.SimpleValue
by Diego Pires Plentz (JIRA)
Incomplete MappingException at org.hibernate.mapping.SimpleValue
----------------------------------------------------------------
Key: HHH-2048
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2048
Project: Hibernate3
Type: Improvement
Versions: 3.2.0.cr4
Reporter: Diego Pires Plentz
When a mapped class has a wrong type, an exception is throwed, but it doesnt say nothing about what class/table is mapped wrongly.
public Type getType() throws MappingException {
if (typeName==null) {
throw new MappingException("No type name");
}
Type result = TypeFactory.heuristicType(typeName, typeParameters);
if (result==null) {
String msg = "Could not determine type for: " + typeName;
if(columns!=null && columns.size()>0) {
msg += ", for columns: " + columns;
}
throw new MappingException(msg);
}
return result;
}
Can become something like this...
public Type getType() throws MappingException {
if (typeName==null) {
throw new MappingException("No type name");
}
Type result = TypeFactory.heuristicType(typeName, typeParameters);
if (result==null) {
String msg = "Could not determine type for: " + typeName;
if(table != null){
msg += ", at table: " + table.getName();
}
if(columns!=null && columns.size()>0) {
msg += ", for columns: " + columns;
}
throw new MappingException(msg);
}
return result;
}
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2739) 'illegal attempt to dereference collection' when referencing a single-valued association in an implicit join
by Martin Kouba (JIRA)
'illegal attempt to dereference collection' when referencing a single-valued association in an implicit join
------------------------------------------------------------------------------------------------------------
Key: HHH-2739
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2739
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: I have found that behaviour in version 3.2.4.sp1 and 3.2.3 (I didn't test 3.2.4 pre sp1)
Database: ORACLE 10g
Reporter: Martin Kouba
After upgrading to the latest Hibernate version I got this error.
I try to use a statement like this
from cat c where c.mate.id = 13
the expected resulting SQL should be something like
SELECT * FROM CAT C WHERE C.MATE_ID = 13
which is much more performant than making a join
from cat c join c.mate m where m.id = 13
which would result in something like that
SELECT * FROM CAT C INNER JOIN MATE M ON C.MATE_ID = M.ID WHERE M.ID = 13
This works as expected in 3.1.3, 3.2.0 and 3.2.2
It doesn't work with version 3.2.3 and with 3.2.4.sp1.
As test case you can take the example from the documentation chapter 5.1.16
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping package="eg">
<class name="Cat" table="CATS">
<id name="id" column="uid" type="long">
<generator class="hilo"/>
</id>
<property name="birthdate" type="date"/>
<property name="color" not-null="true"/>
<property name="sex" not-null="true"/>
<property name="weight"/>
<many-to-one name="mate"/>
<set name="kittens">
<key column="MOTHER"/>
<one-to-many class="Cat"/>
</set>
<joined-subclass name="DomesticCat" table="DOMESTIC_CATS">
<key column="CAT"/>
<property name="name" type="string"/>
</joined-subclass>
</class>
<class name="eg.Dog">
<!-- mapping for Dog could go here -->
</class>
</hibernate-mapping>
c = new Cat();
c.setMate(new Cat());
c.persist();
int id = c.getId();
List results = session.createQuery("from Cat as c where c.mate.id = 16).list();
according to manual section 14.5 this should work
http://www.hibernate.org/hib_docs/v3/reference/en/html_single/#queryhql-i...
Ok, I hope this is clear enough and the test case is clear enough as well.
This is a major stopper for an upgrade. I have reported that on June 11th
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2667
But it seems that others used the same case to report a similar issue regarding automatic joins.
According to Christian Bauer automatic joins are no longer supported, closed the case and told me to reopen it again.
So to all others please do not add comments to this case if it is not about it. And to the Hibernate developers: Greate work you are doing but please I think the issue was clear when I reported it the first time. It is quite easy to reproduce and occurs quite often in a medium size project.
Gratitude
Martin
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2436) Incorrect SQL generation for some select statements with "group by"
by Joseph Marques (JIRA)
Incorrect SQL generation for some select statements with "group by"
-------------------------------------------------------------------
Key: HHH-2436
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2436
Project: Hibernate3
Type: Bug
Versions: 3.2.1
Reporter: Joseph Marques
JPQL was:
SELECT res.resourceType, count(res.resourceType)
FROM ResourceGroup rg JOIN rg.resources res
WHERE rg.id = :id
GROUP BY res.resourceType
It translated to:
select
resource2_.RESOURCE_TYPE_ID as col_0_0_,
count(resource2_.RESOURCE_TYPE_ID) as col_1_0_,
resourcety3_.ID as ID376_,
resourcety3_.NAME as NAME376_,
resourcety3_.DESCRIPTION as DESCRIPT3_376_,
resourcety3_.CATEGORY as CATEGORY376_,
resourcety3_.PLUGIN as PLUGIN376_,
resourcety3_.CTIME as CTIME376_,
resourcety3_.MTIME as MTIME376_,
resourcety3_.PARENT_RESOURCE_TYPE_ID as PARENT8_376_,
resourcety3_.PLUGIN_CONFIG_DEF_ID as PLUGIN9_376_,
resourcety3_.RES_CONFIG_DEF_ID as RES10_376_
from
public.ON_RESOURCE_GROUP resourcegr0_
inner join
public.ON_RESOURCE_GROUP_RES_MAP resources1_
on resourcegr0_.ID=resources1_.RESOURCE_GROUP_ID
inner join
public.ON_RESOURCE resource2_
on resources1_.RESOURCE_ID=resource2_.ID
inner join
public.ON_RESOURCE_TYPE resourcety3_
on resource2_.RESOURCE_TYPE_ID=resourcety3_.ID
where
resourcegr0_.DTYPE in (
'COMPATIBLE', 'MIXED'
)
and resourcegr0_.ID=?
group by
resource2_.RESOURCE_TYPE_ID
The message was:
"ERROR main org.hibernate.util.JDBCExceptionReporter - ERROR: column "resourcety3_.id must appear in the GROUP BY caluse or be used in an aggregate function"
My issue with this is that I only want to select a single object (along with the count of that object when grouped), but the generated SQL seems to be selecting two different objects - resource2_ and resourcety3_. The jdbc error message is perfectly correct; it's the translated SQL that seems a bit off.
Maybe the JPQL syntax I want to use is not supported? Or perhaps I'm just doing something wrong?
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2536) NPE with custom SQL query and formula property
by Jörg Heinicke (JIRA)
NPE with custom SQL query and formula property
----------------------------------------------
Key: HHH-2536
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2536
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.1
Reporter: Jörg Heinicke
Priority: Minor
I have an object Balance which I map like the following (stripped):
<class name="Balance" entity-name="Balance" table="BALANCE">
...
<property name="reportDate" column="report_date" type="..." not-null="true"/>
<property name="year" formula="year(report_date)" type="..."/>
</class>
Now I have another object which is actually a cumulated view of the BALANCE table. For retrieving the values I use a custom SQL query. The mapping is almost the same (it is at least for the properties in question, but e.g. the ID mapping is different as it is a cumulated view).
<class name="PaymentStatisticsData">
...
<property name="reportDate" column="report_date" type="..." not-null="true"/>
<property name="year" formula="year(report_date)" type="..."/>
<loader query-ref="paymentStatisticsData"/>
</class>
<sql-query name="paymentStatisticsData" read-only="true">
<return class="PaymentStatisticsData"/>
select ...
</sql-query>
In theory there should be no difference, but the latter fails with the following NPE:
Caused by: java.lang.NullPointerException
at org.hibernate.loader.DefaultEntityAliases.intern(DefaultEntityAliases.java:133)
at org.hibernate.loader.DefaultEntityAliases.getSuffixedPropertyAliases(DefaultEntityAliases.java:106)
at org.hibernate.loader.DefaultEntityAliases.<init>(DefaultEntityAliases.java:52)
at org.hibernate.loader.ColumnEntityAliases.<init>(ColumnEntityAliases.java:16)
at org.hibernate.loader.custom.sql.SQLQueryReturnProcessor.generateCustomReturns(SQLQueryReturnProcessor.java:174)
at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:129)
at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43)
at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114)
at org.hibernate.impl.SessionFactoryImpl.checkNamedQueries(SessionFactoryImpl.java:444)
at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:351)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1291)
Hope that's all information you need.
Joerg
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2627) Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
by Michael Werle (JIRA)
Generated properties leak prepared statements in Hibernate 3.2.3 and higher.
----------------------------------------------------------------------------
Key: HHH-2627
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2627
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1, 3.2.4, 3.2.3
Environment: Hibernate 3.2.2-4sp1, Oracle 10g (Oracle9Dialect)
Reporter: Michael Werle
Attachments: generated-lazy-statement-leak.patch
The fix for HHH-2393, in combination with a change to AbstractBatcher 11333 to the Hibernate 3.2 branch (comment is "sybase testsuite"), created a PreparedStatement leak for generated properties.
The reason is that, in revision 11333, org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() was changed to check for the existence of the prepared statement in the statementsToClose collection instead of closing it unconditionally. The fix for HHH-2393 (revision 11117 in the Hibernate 3.2 branch) modified org.hibernate.persister.entity.AbstractEntityPersister#processGeneratedProperties() to make it use org.hibernate.jdbc.AbstractBatcher#closeQueryStatement() instead of org.hibernate.jdbc.AbstractBatcher#closeStatement(), which closes the statement without checking the statementsToClose collection. This is a problem because the statement in AbstractEntityPersister#processGeneratedProperties() is created with AbstractBatcher#prepareSelectStatement(), which does not add the statement to the statementsToClose collection.
The attached patch to org.hibernate.persister.entity.AbstractEntityPersister changes processGeneratedProperties() back to using AbstractBatcher#closeStatement() and obtains the result set through ResultSet#executeQuery() instead of using the batcher. This fixes the prepared statement leak and matches other usages of AbstractBatcher#prepareSelectStatement(), which also avoid using the batcher for their result sets. It also makes the same change in AbstractEntityPersister#initializeLazyPropertiesFromDatastore() becuase it has exactly the same problem.
No existing test cases are broken by the attached patch. I investigated ways to write a test case to explicitly verify that the result sets and statements were all being closed. However, because the counts in AbstractBatcher are private, and I do not know of a generic way to obtain counts through the JDBC API, I could not figure out a good way to do so without using reflection to access the private fields, which none of the existing test cases seem to do.
The bug was discovered when running my web app against Oracle, which runs out of cursors when connections are leaked -- not exactly a practical way to write a test case, but sufficient to prove that the bug exists and is fixed by the patch.
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2964) missing column name due to IndexNode.resolve calling queryableCollection.getIndexColumnNames()
by Kay Schubert (JIRA)
missing column name due to IndexNode.resolve calling queryableCollection.getIndexColumnNames()
----------------------------------------------------------------------------------------------
Key: HHH-2964
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2964
Project: Hibernate3
Issue Type: Bug
Components: query-hql
Affects Versions: 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1
Environment: hibernate-core 3.2.5, mysql 5
Reporter: Kay Schubert
Attachments: IndexNode.patch
Declared entities:
@Entity
class Book {
@Id
long id;
@OneToMany(mappedBy = "id.book")
@MapKey(name = "id.stationName")
private Map<String, StationBooksCounter> stationBooksCounter;
}
@Embeddable
class StationBooksCounterPk {
String stationName;
@ManyToOne(optional = false)
Book book;
}
@Entity
class StationBooksCounter {
@EmbeddedId
StationBooksCounterPk id;
int count;
}
HQL: "from Book b where b.stationBooksCounter['key'].count > '0'" results in that
SQL: "select ... from Book book0_ where exists ( select 1 from StationBooksCounter stationboo3_ where books0_.id=stationboo3_.book_id and stationboo3_.null = 'key' and and stationboo3_.count>'0')"
(statements text have been deducted from analogous queries in actual application - I didn't actually compile that simplified test case, since I'm quite sure what the problem is)
The "stationboo3_.null" is caused by IndexNode.resolve calling queryableCollection.getIndexColumnNames() to resolve the index column name. Here queryableCollection is an org.hibernate.persister.collection.AbstractCollectionPersister, and getIndexColumnNames() returns the String[] indexColumnNames, containing only one null element. I changed that to AbstractCollectionPersister.getIndexColumnNames(String tableAlias). It uses indexColumnNames as well as indexFormulaTemplates to build the SQL fragment.
--
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
18 years, 4 months
[Hibernate-JIRA] Created: (HHH-2966) Create table fails for SchemaExport when a column is mapped again with insert="false" update="false"
by Varghese C V (JIRA)
Create table fails for SchemaExport when a column is mapped again with insert="false" update="false"
----------------------------------------------------------------------------------------------------
Key: HHH-2966
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2966
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate-3.2.5, Hsqldb-1.8.0.7
Reporter: Varghese C V
Attachments: org.hibernate.mapping.Table.patch, repeated-column-mapping-test-case.zip
AbstractCustomer mapping :
<hibernate-mapping>
<class name="org.hibernate.test.schemaexport.AbstractCustomer" abstract="true">
<id name="id" type="java.lang.String">
<column name="ID" length="20" />
<generator class="assigned" />
</id>
<property name="countryCode" type="java.lang.String">
<column name="COUNTRY_CODE" length="2" />
</property>
</class>
</hibernate-mapping>
CorporateCustomer mapping :
<hibernate-mapping>
<union-subclass name="org.hibernate.test.schemaexport.CorporateCustomer" extends="org.hibernate.test.schemaexport.AbstractCustomer">
<many-to-one name="country" class="org.hibernate.test.schemaexport.Country" insert="false" update="false">
<column name="COUNTRY_CODE" length="2" />
</many-to-one>
</union-subclass>
</hibernate-mapping>
For these mappings, the ddl generated by SchemaExport contains the COUNTRY_CODE twice.
Generated Sql
create table CorporateCustomer (
ID varchar(20) not null,
COUNTRY_CODE varchar(2),
COUNTRY_CODE varchar(2),
primary key (ID)
)
I have attached a test case that reproduces this.
I have also attached a patch to org.hibernate.mapping.Table to fix this problem. The patch is simply to skip the duplicate columns when the sql is being generated.
Please do verify.
--
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
18 years, 4 months