July 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6371) Develop metamodel binding creation using a push approach

by Steve Ebersole (JIRA)

Develop metamodel binding creation using a push approach --------------------------------------------------------- Key: HHH-6371 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6371 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next However, for our normal use re-purpose the "state" stuff and act as a "normalized view of mapping information" and have binders consume that to create the bindings. -- 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

13 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6440) Hibernate + Webstart + JnlpDownloadServlet: problem with JAR names

by Ramon Casha (JIRA)

Hibernate + Webstart + JnlpDownloadServlet: problem with JAR names ------------------------------------------------------------------ Key: HHH-6440 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6440 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.6 Reporter: Ramon Casha I have created a webapp to deploy my application using Java Web Start, and I'm using the standard JnlpDownloadServlet to provide different file versions. For instance, the JNLP file would reference entities.jar, but the physical file on the web server might be entities-1.0.2.jar. This is normally handled by the web start internals, but Hibernate attempts to access the JAR file directly (I think to find the entities), using the "original" JAR file name without a version. I believe the problem is in org.hibernate.ejb.packaging.JarVisitorFactory, in the function getJarURLFromURLEntry. This method takes a "jar:" URL and extracts from it the embedded "http:" URL. However this http URL does not have the version number included. Presumably the protocol handler for the jar protocol handles this internally. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6438) Consider changing Constraint.getName() to return Identifier

by Gail Badner (JIRA)

Consider changing Constraint.getName() to return Identifier ----------------------------------------------------------- Key: HHH-6438 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6438 Project: Hibernate Core Issue Type: Task Components: metamodel Reporter: Gail Badner -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6437) Improve Database to track default Schema object

by Steve Ebersole (JIRA)

Improve Database to track default Schema object ----------------------------------------------- Key: HHH-6437 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6437 Project: Hibernate Core Issue Type: Improvement Components: core, metamodel Affects Versions: 4.0.0.Beta3 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Deleted: (HHH-6435) Rename o.h.metamodel.relational.Schema

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-6435?page=c... ] Steve Ebersole deleted HHH-6435: -------------------------------- > Rename o.h.metamodel.relational.Schema > -------------------------------------- > > Key: HHH-6435 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6435 > Project: Hibernate Core > Issue Type: Improvement > Reporter: Steve Ebersole > Assignee: Steve Ebersole > > Rename to avoid confusion with "schema" when talking about schema/catalog config values. To be honest though, not really sure of a better name -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6435) Rename o.h.metamodel.relational.Schema

by Steve Ebersole (JIRA)

Rename o.h.metamodel.relational.Schema -------------------------------------- Key: HHH-6435 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6435 Project: Hibernate Core Issue Type: Improvement Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next Rename to avoid confusion with "schema" when talking about schema/catalog config values. To be honest though, not really sure of a better name -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4630) Criteria join on composite identifier generates wrong alias, SQL error

by Chris Wilson (JIRA)

Criteria join on composite identifier generates wrong alias, SQL error ---------------------------------------------------------------------- Key: HHH-4630 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4630 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: Hibernate trunk from 2009-11-30, Ubuntu 8.04, Sun Java 1.6.0-17, MySQL 5.0.51a-3ubuntu5.4 Reporter: Chris Wilson Attachments: hibernate-invalid-alias-generation.patch Hibernate generates the wrong alias on a Criteria query involving a join on a composite identifier. For example, in the test below without the fix to JoinWalker, it generates this SQL: select this_.role_code as role1_0_1_, this_.is_deleted as is2_0_1_, this_.record_version as record3_0_1_, complexjoi3_.code as code1_0_, complexjoi3_.is_deleted as is2_1_0_, complexjoi3_.record_version as record3_1_0_ from list_action_roles this_ left outer join roles complexjoi3_ on this_.role_code=complexjoi3_.code where this_.is_deleted=? and complexjoi1_.is_deleted=? Which results in this error from the SQL server: Unknown column 'complexjoi1_.is_deleted' in 'where clause' Analysis of the problem: The entity persister class with the composite identifier has a fake property for it, called "_identifierMapper" (see HbmBinder.bindCompositeId() and similarly in Annotations). This property name ends up in the path used by JoinWalker.walkEntityTree() when it calls walkComponentTree(). However that path is used by CriteriaJoinWalker.generateTableAlias() to look up the correct criteria (and hence the alias) from the translator, a CriteriaQueryTranslator. The alias was created in CriteriaQueryTranslator.createCriteriaSQLAliasMap for a Criteria without this extra _identifierMapper path component. So when CriteriaJoinWalker tries to use the path with _identifierMapper to look up the criteria to find the correct alias to use, in generateTableAlias(), it doesn't find one, so it generates a new alias. That new alias no longer matches the one that will be rendered out in the WHERE clause, so the WHERE clause will refer to table names using aliases that are not used anywhere else in the query, and the SQL server will fail to parse the statement. The solution appears to be to exclude "_identifierMapper" components in the alias path when building it. I don't know what other implications that might have, but it seems like an implementation nastiness that shouldn't be exposed. Patch attached. -- 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

13 years, 8 months

4
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6432) ConnectionManager doesn't call closeStatements on AbstractBatcher when release mode is AFTER_TRANSACTION

by Shawn Clowater (JIRA)

ConnectionManager doesn't call closeStatements on AbstractBatcher when release mode is AFTER_TRANSACTION -------------------------------------------------------------------------------------------------------- Key: HHH-6432 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6432 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.2 Environment: Java 1.6 u25, Win7, Oracle10 Reporter: Shawn Clowater Priority: Minor I was running into issues where I was encountering a NPE out of the checkRowCounts of BatchingBatcher. It was happening when I had an initial session, successfully managed to batch some entities and then encountered a validation exception causing the transaction to be rolled back. Upon trying to insert the same type of data in a second session resulted in the NPE due to the fact that it was still picking up the batched data from the previous session. There ended up being a few things in play here. One of the core snarls was that when using C3P0 it has the ability to cache statements and that's where it was picking up the old batch from the initial transaction. I fully think that's a bug on their part and once I knew what to look for stumbled across this http://sourceforge.net/tracker/?func=detail&aid=3001125&group_id=25357&at... I was able to work around it by implementing my own BatchFactory and on the closeStatements() and closeStatement() and calling clearBatch() on the statement prior to closing it. However, I still needed to call closeStatements() explicitly since the connectionManager wasn't calling it in my case. The code in the ConnectionManager in 3.6.2 looks like {code} public void afterTransaction() { if ( isAfterTransactionRelease() ) { aggressiveRelease(); } else if ( isAggressiveReleaseNoTransactionCheck() && batcher.hasOpenResources() ) { log.info( "forcing batcher resource cleanup on transaction completion; forgot to close ScrollableResults/Iterator?" ); batcher.closeStatements(); aggressiveRelease(); } else if ( isOnCloseRelease() ) { // log a message about potential connection leaks log.debug( "transaction completed on session with on_close connection release mode; be sure to close the session to release JDBC resources!" ); } batcher.unsetTransactionTimeout(); } {code} You can clearly see that the batcher.closeStatements() isn't called in the first case. What's even worse is that in the aggressiveRelease() call it nulls out the connection so even when the Session is physically closed and it calls back to the ConnectionManager.close() method and ultimately the cleanup() it gets into here and just returns. {code} if ( connection == null ) { log.trace( "connection already null in cleanup : no action"); return null; } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-808) Add an option to SearchConfiguration to disable warnings about missing transactions

by Sanne Grinovero (JIRA)

Add an option to SearchConfiguration to disable warnings about missing transactions ----------------------------------------------------------------------------------- Key: HSEARCH-808 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-808 Project: Hibernate Search Issue Type: Task Components: integration Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Alpha1 This relates to Infinispan's issue ISPN-1218: the Search event listener is logging many warnings about not being properly bound to a transaction manager; it should be made possible for other integrating frameworks not tell the Query engine we don't care for this and that a warning is unnecessary. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-792) Consider renaming LockFactoryFactory to LockFactoryProvider

by Emmanuel Bernard (JIRA)

Consider renaming LockFactoryFactory to LockFactoryProvider ----------------------------------------------------------- Key: HSEARCH-792 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-792 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Emmanuel Bernard Fix For: 4.0.0.Alpha1 -- 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

13 years, 8 months

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2011