[Hibernate-JIRA] Created: (HHH-2113) Incorrect join ordering with filters and JOINED inheritance
by Barney Boisvert (JIRA)
Incorrect join ordering with filters and JOINED inheritance
-----------------------------------------------------------
Key: HHH-2113
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2113
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr4
Environment: Hibernate 3.2.0 CR4, MySQL 4.1.20
Reporter: Barney Boisvert
I've a TextBlock object that extends AbstractContentObject (and has myriad other associations illustrated here, but irrelevant) and when doing a polymorphic query for all AbstractContentObjects Hibernate runs this SQL (note the line with the trailing asterisks):
select
textblockv0_.id as id21_5_,
textblockv0_.createTimestamp as createTi2_21_5_,
textblockv0_.hibernateVersionId as hibernat3_21_5_,
textblockv0_.lastUpdateTimestamp as lastUpda4_21_5_,
textblockv0_.lastVersionNumber as lastVers5_21_5_,
textblockv0_.activeVersionId as activeVe6_21_5_,
textblockv1_.id as id20_0_,
textblockv1_.createTimestamp as createTi2_20_0_,
textblockv1_.hibernateVersionId as hibernat3_20_0_,
textblockv1_.lastUpdateTimestamp as lastUpda4_20_0_,
textblockv1_.versionNumber as versionN5_20_0_,
textblockv1_.frozen as frozen20_0_,
textblockv1_.commitMessage as commitMe7_20_0_,
textblockv1_.title as title20_0_,
textblockv1_.summary as summary20_0_,
textblockv1_.text as text20_0_,
textblockv1_.versionHistoryId as version11_20_0_,
textblockv2_.id as id21_1_,
textblockv2_.createTimestamp as createTi2_21_1_,
textblockv2_.hibernateVersionId as hibernat3_21_1_,
textblockv2_.lastUpdateTimestamp as lastUpda4_21_1_,
textblockv2_.lastVersionNumber as lastVers5_21_1_,
textblockv2_.activeVersionId as activeVe6_21_1_,
textblock3_.id as id18_2_,
textblock3_1_.createTimestamp as createTi2_18_2_,
textblock3_1_.hibernateVersionId as hibernat3_18_2_,
textblock3_1_.siteId as siteId18_2_,
textblock3_1_.orderCol as orderCol18_2_,
textblock3_1_.folderId as folderId18_2_,
textblock3_.versionHistoryId as versionH2_19_2_,
site4_.id as id1_3_,
site4_.createTimestamp as createTi2_1_3_,
site4_.hibernateVersionId as hibernat3_1_3_,
site4_.lastUpdateTimestamp as lastUpda4_1_3_,
site4_.name as name1_3_,
site4_.parentId as parentId1_3_,
site4_.timeZone as timeZone1_3_,
site4_.familyId as familyId1_3_,
site4_.externalSiteAccessControl as external7_1_3_,
site4_.canonicalDomainId as canonic10_1_3_,
folder5_.id as id17_4_,
folder5_.createTimestamp as createTi2_17_4_,
folder5_.hibernateVersionId as hibernat3_17_4_,
folder5_.lastUpdateTimestamp as lastUpda4_17_4_,
folder5_.leftCol as leftCol17_4_,
folder5_.rightCol as rightCol17_4_,
folder5_.siteId as siteId17_4_,
folder5_.title as title17_4_
from
TextBlockVersionHistory textblockv0_
left outer join
TextBlockVersion textblockv1_
on textblockv0_.activeVersionId=textblockv1_.id
left outer join
TextBlockVersionHistory textblockv2_
on textblockv1_.versionHistoryId=textblockv2_.id
left outer join
TextBlock textblock3_
on textblockv0_.id=textblock3_.versionHistoryId
and ? = textblock3_1_.siteId -- **************************************************
left outer join
AbstractContentObject textblock3_1_
on textblock3_.id=textblock3_1_.id
left outer join
Site site4_
on textblock3_1_.siteId=site4_.id
left outer join
Folder folder5_
on textblock3_1_.folderId=folder5_.id
where
textblockv0_.id=?
The highlighted condition is applied via a filter on AbstractContentObject:
@javax.persistence.Entity
@Inheritance(strategy = InheritanceType.JOINED)
@Filter(name = "siteVisibility", condition = ":siteId = siteId")
@Table(uniqueConstraints = @UniqueConstraint( columnNames = { "folderId", "order"}))
public abstract class AbstractContentObject
However, the actual SQL condition is supplied to the wrong LEFT OUTER JOIN. It should be supplied against the AbstractContentObject JOIN that immediately follows the condition. I.e. move the condition down three lines, and it should work.
--
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
17 years, 3 months
[Hibernate-JIRA] Created: (HHH-2631) Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
by Douglas A. Herrick (JIRA)
Leaking PreparedStatement and ResultSet via CollectionLoadContext instances maintained in Map collectionLoadContexts in LoadContexts
------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2631
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2631
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Environment: hibernate 3.2.3 with patch from HHH-2553
Reporter: Douglas A. Herrick
Priority: Critical
While diagnosing an apparent resource issue, while running our application for a couple of hours I noticed over time that the number of PreparedStatement and ResultSet instances continued to grow, eventually consuming a fair amount of memory. After digging around a bit, I saw that the entries LoadContext.java inserts into the map named collectionLoadContexts are not removed from the map [method cleanup(ResultSet resultSet) might have removed them, but I never witnessed its invocation, nor did I find any references to it).
I pasted below a stack trace that shows the insertion of elements into collectionLoadContexts:
Thread [http-9943-Processor2] (Suspended (breakpoint at line 53 in CollectionLoadContext))
CollectionLoadContext.<init>(LoadContexts, ResultSet) line: 53
LoadContexts.getCollectionLoadContext(ResultSet) line: 85
BasicCollectionLoader(Loader).handleEmptyCollections(Serializable[], Object, SessionImplementor) line: 1060
BasicCollectionLoader(Loader).doQuery(SessionImplementor, QueryParameters, boolean) line: 690
BasicCollectionLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 236
BasicCollectionLoader(Loader).loadCollection(SessionImplementor, Serializable, Type) line: 1994
BasicCollectionLoader(CollectionLoader).initialize(Serializable, SessionImplementor) line: 36
BasicCollectionPersister(AbstractCollectionPersister).initialize(Serializable, SessionImplementor) line: 565
DefaultInitializeCollectionEventListener.onInitializeCollection(InitializeCollectionEvent) line: 60
SessionImpl.initializeCollection(PersistentCollection, boolean) line: 1716
PersistentSet(AbstractPersistentCollection).forceInitialization() line: 454
StatefulPersistenceContext.initializeNonLazyCollections() line: 785
QueryLoader(Loader).doQueryAndInitializeNonLazyCollections(SessionImplementor, QueryParameters, boolean) line: 241
QueryLoader(Loader).doList(SessionImplementor, QueryParameters) line: 2220
QueryLoader(Loader).listIgnoreQueryCache(SessionImplementor, QueryParameters) line: 2104
QueryLoader(Loader).list(SessionImplementor, QueryParameters, Set, Type[]) line: 2099
QueryLoader.list(SessionImplementor, QueryParameters) line: 378
QueryTranslatorImpl.list(SessionImplementor, QueryParameters) line: 338
HQLQueryPlan.performList(QueryParameters, SessionImplementor) line: 172
SessionImpl.list(String, QueryParameters) line: 1121
QueryImpl.list() line: 79
HibQuery.list() line: 60
HibRepository(AbstractRepository).query(IQuery, Class) line: 300
...
While subsequent to this logic, hibernate does close the PreparedStatement and ResultSet instances, since it never removes them from collectionLoadContexts map, those instances are never GCed. After running our application for a couple of days the amount of storage attributed to this potential leak is significant.
--
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
17 years, 3 months
[Hibernate-JIRA] Created: (HHH-2365) Incorrect parameter order for parameters used as map-key in HQL
by Hendrik D (JIRA)
Incorrect parameter order for parameters used as map-key in HQL
---------------------------------------------------------------
Key: HHH-2365
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2365
Project: Hibernate3
Type: Bug
Components: query-hql
Versions: 3.2.1
Reporter: Hendrik D
When using parameters in HQL for the key of a domain object map in the where-clause, the query parsing mechanism results in an SQL query with the parameters used in the wrong places.
Since my real domain objects require you to know too much of the application I'm writing, I'll describe the problem with a simplified setup:
CLASSES:
-------
class Foo {
int id;
int meaninglessNumber;
Map<Language, Document> documents;
}
class Document {
int id;
String name;
}
class Language {
String code;
}
TABLES:
-------
FOO
id
meaninglessNumber
documents_link_id
DOCUMENTS_LINK
documents_link_id
language_code
document_id
name
LANGUAGE
language_code
Now, let't try to retrieve all Foo that contain an english document with name "English", and have a meaninglessNumber of '5'. This is the HQL I produce:
from Foo as foo
where foo.meaninglessNumber = param1
and foo.documents[:param2]=:param3
These are the parameter values:
param1 = int 5
param2 = Language {code="en"}
param3 = String "English"
I expect an sql query like this:
select *
from foo foo0_
inner join documents documents1_
where foo0_.documents_link_id = documents1_.documents_link_id
and documents1_.language_code = 'en'
and foo0_.meaninglessNumber = 5
and documents1_.name = 'English'
But instead, the real query looks like this:
select *
from foo foo0_
inner join documents documents1_
where foo0_.documents_link_id = documents1_.documents_link_id
and documents1_.language_code = 5
and foo0_.meaninglessNumber = 'en'
and documents1_.name = 'English'
The subtle difference is, that the parameters param1 and param2 seem to be switched! A lot of debugging pointed out that the order of the indexes is determined based on the HQL, resulting in the following indexes:
param1 -> 1
param2 -> 2
param3 -> 3
In the generated SQL, all parameters are replaced by '?', and on execution, these are replaced one by one, following the order of the parameter indexes.
While creating the SQL, the map key parameter is transformed into 'documents1_.language_code = ?'. No problem here, but this condition is placed in the beginning of the where clause, before the use of parameter param1. The indexes of the parameters should become:
param2 -> 1
param1 -> 2
param3 -> 3
But this is never done!
I see 3 possible ways to fix this:
- Recalculate the indexes of the parameters when the sql is generated
- Generate the sql in the right position, so the order of the parameters stays the same
- Use named parameters in the sql and only replace them with '?' right before creating the PreparedStatement. This seems to me the most reliable way, but I guess I'm missing the point of calculating the parameter indexes and replacing them with '?' immediately...
Hendrik
--
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
17 years, 3 months
[Hibernate-JIRA] Created: (HHH-2496) Parameter binding in wrong order when filter adds params
by David Sheldon (JIRA)
Parameter binding in wrong order when filter adds params
--------------------------------------------------------
Key: HHH-2496
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2496
Project: Hibernate3
Type: Bug
Components: query-hql
Environment: Hibernate version: 3.2
Database: Postgresql 8.1.6
Reporter: David Sheldon
it seems that if you use a filter in the "order by" clause of your query, it binds the parameters in the wrong order. I've been looking through the code, and couldn't work out where the binding of filter parameters take place. Am I doing something wrong here, or is this a bug? I don't get an exception, but the query returns the wrong data because the parameters are sent to the database in the wrong order.
Mapping documents:
<hibernate-mapping>
<class name="bug.Event" table="events">
<id name="id" column="event_id">
<generator class="native"/>
</id>
<property name="date" type="timestamp" column="timestamp" />
</class>
<class name="bug.Thing" table="things">
<id name="id" column="id">
<generator class="native"/>
</id>
<property name="name" type="string" />
<list name="events" lazy="true" table="things_to_events" cascade="save-update,delete,delete-orphan">
<key column="thing_id"/>
<list-index column="index"/>
<many-to-many class="bug.Event" column="event_id"/>
<filter name="dateFilter" condition="event_id in (select events.event_id from events where events.timestamp between :startDate and :endDate)"/>
</list>
</class>
<filter-def name="dateFilter">
<filter-param name="startDate" type="date"/>
<filter-param name="endDate" type="date"/>
</filter-def>
</hibernate-mapping>
Code between sessionFactory.openSession() and session.close():
Thing t = new Thing();
t.setName("bob");
Event e = new Event();
e.setDate(new Date());
t.setEvents(Collections.singletonList(e));
session.save(e);
session.save(t);
session.enableFilter("dateFilter").setParameter("startDate", new GregorianCalendar(2007, 1, 20).getTime()).setParameter("endDate", new GregorianCalendar(2007, 2, 20).getTime());
Query query = session.createQuery("From Thing Where name = :name order by size(events)");
query.setParameter("name", "bob");
System.err.println("Size: " + query.list().size());
The generated SQL (show_sql=true):
Hibernate: select thing0_.id as id1_, thing0_.name as name1_ from things thing0_ where thing0_.name=? order by (select count(events1_.thing_id) from things_to_events events1_ where thing0_.id=events1_.thing_id and events1_.event_id in (select events.event_id from events where events.timestamp between ? and ?))
Debug level Hibernate log excerpt:
[java] 11:21:31,176 DEBUG AbstractBatcher:476 - preparing statement
[java] 11:21:31,177 DEBUG DateType:133 - binding '20 February 2007' to parameter: 1
[java] 11:21:31,178 DEBUG DateType:133 - binding '20 March 2007' to parameter: 2
[java] 11:21:31,179 DEBUG StringType:133 - binding 'bob' to parameter: 3
As you can see, "bob" should be bound to parameter 1, 20th Feb to 2, and 20th March to 3.
--
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
17 years, 3 months
[Hibernate-JIRA] Created: (HHH-2018) Cannot map views in postgres unless hbm2ddl.auto is unset
by Dave E Martin (JIRA)
Cannot map views in postgres unless hbm2ddl.auto is unset
---------------------------------------------------------
Key: HHH-2018
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2018
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr2
Environment: hibernate 3.2cr2 annotations 3.2cr1 postgresql 8.1 with postgresql-8.1-404.jdbc3.jar
This is also a problem in hibernate 3.1
Reporter: Dave E Martin
Attempting to map a view with hibernate results in:
Exception in thread "main" org.hibernate.HibernateException: Missing table: monthly_block_totals_utc
Even though this exists (as a view) in the database.
making sure hbm2ddl.auto is not set allows the application to work, but at the expense of being unable to update or validate the schema (or allow the end user to control whether the schema should be updated or not).
Furthermore, there doesn't appear to be a 'none' or any documented way to set .auto to something which would be the equivalent of it not being set. (or to clear it out of the properties, and setting it to null doesn't work either).
This appears to be related to HHH-1329 and HHH-1473.
Stepping into the process reveals that postgres apparently reports views as views and not tables, causing them to be overlooked by Hibernate when its validating.
--
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
17 years, 3 months
[Hibernate-JIRA] Created: (HHH-2490) ClassCastException causes a logging statement to throw another ClassCastException upon inconsistent instantiation of NullableType
by Øyvind Roth (JIRA)
ClassCastException causes a logging statement to throw another ClassCastException upon inconsistent instantiation of NullableType
---------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2490
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2490
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.2
Environment: MS SQLServer
Windows 2000
Java 1.5.0_10
Reporter: Øyvind Roth
(Have me excused that I don't know well the internalities of Hibernate,
but I think that you get the point from some kind of "bird's perpective" anyhow).
My pojo is defined in my xml mapping with a column/field as follows:
...
<property name="encrypted"
type="string"
column="encrypted"
insert="true"
update="true"
not-null="true"/>
...
The corresponding POJO class is defined with two access methods:
String getEncrypted();
and
boolean isEncrypted();
The field is a String with possible values "f" or "t".
Of convenience reasons I have added a parallell method
operating on boolean. My database is designed with a CHAR(1)
for booleans. (All this because the dam... RDBMS standard doesn't
advice a consistent boolean data type, a really big blunder from
time back in System R. OT ok, but I got it out.)
When Hibernate parses my instantiated pojo, a Boolean instance is
generated. But it's "repository" is prepared with a StringType as a
consequence of my XML configuration file. During the course, the
method nullSafeSet of class NullableType is called with the value
parameter Boolean. Eventually the
"public abstract String toString(Object value) throws HibernateException;"
method is called for StringType, which is implemented with a simple typecast.
Exception received. Whether this behavior is ok or not is one discussion.
But there's a second problem to it also: When the exception is received,
NullableType tries to log the event:
...
catch ( RuntimeException re ) {
log().info( "could not bind value '" + nullSafeToString( value ) + "' to parameter: " + index + "; " + re.getMessage() );
throw re;
}
...
And the same shit happens again. So the developer does not receive the actual exception,
but the exception received from the logging statement. A strong golden rule of thumb:
A logging statement should never ever throw. This is what I would call a bug in Hibernate.
Setting the log level to ERROR will of course not solve the problem,
because the string paramater is evaluated before the log statement is ever reached.
A variant of this issue is described under: "HHH-2034"
--
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
17 years, 3 months