September 2007 - hibernate-issues

[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

18 years, 3 months

3
4
0 / 0

[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

18 years, 3 months

7
19
0 / 0

[Hibernate-JIRA] Created: (HHH-2858) NestableRuntimeException instvar 'cause'

by Jakob Braeuchi (JIRA)

NestableRuntimeException instvar 'cause' ----------------------------------------- Key: HHH-2858 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2858 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: all Reporter: Jakob Braeuchi Priority: Minor The instance variable 'cause' in NestableRuntimeException duplicates the instvar 'cause' in Throwable. from Throwable: /** * The throwable that caused this throwable to get thrown, or null if this * throwable was not caused by another throwable, or if the causative * throwable is unknown. If this field is equal to this throwable itself, * it indicates that the cause of this throwable has not yet been * initialized. * * @serial * @since 1.4 */ private Throwable cause = this; Refactoring NestableRuntimeException should be easy. Jakob -- 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, 3 months

2
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1329) SchemaValidator fail when views are involved

by Yariv Yaari (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1329?page=c... ] Yariv Yaari commented on HHH-1329: ---------------------------------- Although adding the VIEW would probably work on most databases, at least as far as vies are concerned, shouldn't the solution be more general? What about other types of tables like "Materialized views" in oracle that might be tables of a different type? Why restrict the user if the object can be treated as a table? In the API of this method (getTables) It is specified that the fourth parameter (tableTypes) can be null, so that all types will be returned. Why not pass null? > SchemaValidator fail when views are involved > -------------------------------------------- > > Key: HHH-1329 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1329 > Project: Hibernate3 > Issue Type: Bug > Components: metamodel > Affects Versions: 3.1 > Environment: database: oracle9i > hibernate: 3.1 > jdbc driver: ojdbc14-10.2.0.1.0 > Reporter: Yariv Yaari > Assignee: Diego Pires Plentz > > All calls in org.hibernate.tool.hbm2ddl.DatabaseMetadata.getTableMetadata to java.sql.DatabaseMetaData.getTables set the fourth parameter (types) to {"TABLE"} (defined as a class-level constant). > In the documentation of getTables it is not defined what are the meanings of the types passed as parameter, only that all the strings must be in java.sql.DatabaseMetaData.getTablesTypes return value. In oracle9i with ojdbc14-10.2.0.1.0.jar views are returned if types contains "VIEW" and not if its {"TABLE"}. It is a major problem only if hibernate.hbm2ddl.auto is set to validate, if it's set to update it will log some errors (since it can't create or alter the table, there is a view with this name) but it won't fail the deployment, and since in SQL views are treated as tables, there will be no more problems. > It should be checked for more databases/jdbc drivers. > It is not obvious what should be the solution. > Pass {"TABLE","VIEW"} always? Pass them if they are in getTableTypes? > Put it as part of the dialect, default to {"TABLE"} and change it in oreacle-dialects? -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1280) Cascade refresh and new instances

by Reto Urfer (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1280?page=c... ] Reto Urfer updated HHH-1280: ---------------------------- Attachment: patch.zip patch files for my fix. Class EntityAction.java does no longer need changes, all used resources are now accessible. > Cascade refresh and new instances > --------------------------------- > > Key: HHH-1280 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1280 > Project: Hibernate3 > Issue Type: Bug > Components: core > Reporter: Gavin King > Attachments: Fix.zip, patch.zip > > > I have a report that if you have a managed object, with a reference to a new object, where cascade refresh is enabled, and you refresh the managed object, then you will get an exception as refresh tries to cascade to the new object. In fact, the new object should just be ignored. > Looking at the code, this does appear to be the case. -- 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, 3 months

1
0
0 / 0

[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

18 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-122) Remove query.setIndexProjection (replaced by query.setProjection)

by Emmanuel Bernard (JIRA)

Remove query.setIndexProjection (replaced by query.setProjection) ----------------------------------------------------------------- Key: HSEARCH-122 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-122 Project: Hibernate Search Issue Type: Deprecation Components: query Affects Versions: 3.0.0.cr1 Reporter: Emmanuel Bernard Priority: Minor Fix For: 3.0.0.GA -- 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, 3 months

1
1
0 / 0

[Hibernate-JIRA] Resolved: (HHH-1951) Table using back-tick not passing validation on Oracle

by Diego Pires Plentz (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1951?page=c... ] Diego Pires Plentz resolved HHH-1951. ------------------------------------- Assignee: Diego Pires Plentz Resolution: Duplicate > Table using back-tick not passing validation on Oracle > ------------------------------------------------------ > > Key: HHH-1951 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1951 > Project: Hibernate3 > Issue Type: Bug > Affects Versions: 3.1.3 > Environment: Client: Hibernate 3.1.3, Java 1.5.0_06, Mac OS X 10.4.7 > Database server: Windows XP SP2, Oracle XE > Reporter: Matt Solnit > Assignee: Diego Pires Plentz > > I have a table mapping that looks similar to the following: > <class name="User" table="`User`"> >  > Notice the back-ticks around the table name. > When I use Hibernate to create the schema for me, it correctly generates a table name called "User" (including the quote marks). But when I validate the schema, it cannot find the table and so validation fails. > I am thinking the problem is somewhere in org/hibernate/tool/hbm2ddl/DatabaseMetadata.getTableMetadata(). It tries to look for "USER", because OracleDatabaseMetaData.storesUpperCaseIdentifiers() returns true. But the code doesn't realize that quoted tables are a special case and it has to look for "User" instead. > Another symptom of the same problem is that if I generate a schema update script, it will attempt to re-create the existing table. -- 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, 3 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2718) CLONE -Mapping DTD has changed from 3.0. A 3.1 version should be released and made available

by Markus Maier (JIRA)

CLONE -Mapping DTD has changed from 3.0. A 3.1 version should be released and made available -------------------------------------------------------------------------------------------- Key: HHH-2718 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2718 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.1 beta 2 Environment: All Reporter: Markus Maier The Hibernate mapping DTD has changed in at least 1 detail, the lazy attribute of the various Hibernate collections elements now supports {true, false, extra} rather than only {true, false} as in 3.0. I realize that you ship the DTD's in the Hibernate jars, so the differences are not likely to effect the code, but XML editing tools will probably declare otherwise valid documents invalid, since they are likely to access the DTD via the web rather than the jar. If the DTD references in the distributed hbm.xml files were modified then all of the changes would be in sync. -- 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, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2504) Incorrect SQL generated by Oracle/Oracle9 dialects when using composite IDs as keys

by Laurent Pireyn (JIRA)

Incorrect SQL generated by Oracle/Oracle9 dialects when using composite IDs as keys ----------------------------------------------------------------------------------- Key: HHH-2504 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2504 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: Java 1.4/1.5, Windows XP, Oracle 8/9/10 Reporter: Laurent Pireyn This issue is a clone of HHH-683, which has been rejected without any explanation. The problem described then is still very annoying... -- 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, 3 months

3
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2007