March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Closed: (HBX-275) Add SQL preview when executing HQL

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-275?page=co... ] Steve Ebersole closed HBX-275. ------------------------------ Closing stale resolved issues > Add SQL preview when executing HQL > ---------------------------------- > > Key: HBX-275 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-275 > Project: Hibernate Tools > Issue Type: New Feature > Components: consoleconfiguration > Reporter: Etienne Laverdiere > Priority: Minor > Fix For: 3.1alpha5 > > > Hi, > I have post a new about this at http://forum.hibernate.org/viewtopic.php?t=941438&highlight= > I was asking that question : > -- In the "Tool Alpha Edition", is there a way to see the actual SQL generated by Hibernate in the Hibernator Query View when executing an HQL? It would be great to see a equivalent of the "hibernate.show_sql=true"? -- > Can this feature be added? > Thanks. > Etienne. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-910) Queries consume more and more clockticks as Session life goes on

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-910?page=co... ] Steve Ebersole closed HHH-910. ------------------------------ Closing stale resolved issues > Queries consume more and more clockticks as Session life goes on > ---------------------------------------------------------------- > > Key: HHH-910 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-910 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 beta 2 > Environment: Confirmed on WinXP+MSSQL and OS X+MySQL. > Hibernate 3.1b2, one Session per thread. > Reporter: Karl Wettin > Priority: Critical > Original Estimate: 8h > Remaining Estimate: 8h > > I haven't had time to trace it down in the Hibernate source code yet. I'll do it later this week if nobody beats me to it. > As I have been importing huge amounts of data to my database, data that might be updates and that might be creations, I've have noticed that the querys takes more and more time. Starting at 3ms, 50000 queries later at 10 seconds to execute. In the begining I though it took more and more time since the number of rows in my tables grew, but 10 seconds? makePersistent and commit never took more time, just queries. > So then I decided to commit the transaction and recreate the Session every 50 instances made pesistent. Now it stays down. So there is something really bad going on with the Session. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1148) MultipleHiLoPerTableGenerator generates incorrect primary key

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1148?page=c... ] Steve Ebersole closed HHH-1148. ------------------------------- Closing stale resolved issues > MultipleHiLoPerTableGenerator generates incorrect primary key > ------------------------------------------------------------- > > Key: HHH-1148 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1148 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0.5 > Environment: Hibernate 3.05, Sybase 12.5.1, Tomcat 5.0.28 + Websphere 6.02 > Reporter: Jim H > Priority: Minor > > When I insert a new record for any class mapped using the MultipleHiLoPerTableGenerator I am getting incorrect primary key values assigned. The key for each record is (32768 x correct value). So if the correct value should be 1 the assigned pk is 32768. The next record's pk becomes 65536, then 98304, etc. The hi value updated in the next id table is correct. The primary key is of type int. > I was able to alter MultipleHiLoPerTableGenerator.java to return the correct values by replacing the line > maxLo = PropertiesHelper.getInt(MAX_LO, params, Short.MAX_VALUE); > with > maxLo = 0; > There is a posting on the forum (http://forum.hibernate.org/viewtopic.php?t=949810) that has more info. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-962) org.hibernate.dialect.IngresDialect no longer works with paged queries

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-962?page=co... ] Steve Ebersole closed HHH-962. ------------------------------ Closing stale resolved issues > org.hibernate.dialect.IngresDialect no longer works with paged queries > ---------------------------------------------------------------------- > > Key: HHH-962 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-962 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1 rc3 > Environment: JBoss 4.0.3RC2, EJB3RC2, Java1.5_04, Ingres 3.0.2, WinXP > Reporter: Stefan Lindner > Attachments: IngresDialectFix.patch > > > Thsi issue is related to the Ingres support of EJB/Hibernate 3.1 Beta 3 > The following code fragment worked with EJB Beta1 > Query q = manager.createQuery("Select org FROM OrganisationBean org"); > query.setMaxResults(1); > OrganisationBean ob = (OrganisationBean)(query.getSingleResult()); > It does not work anymore with EJB3RC1/RC2. The error messge now is > javax.ejb.EJBTransactionRolledbackException = null; CausedByException is: > paged queries not supported > My dialect is set to org.hibernate.dialect.IngresDialect > <property name="hibernate.dialect" value="org.hibernate.dialect.IngresDialect" /> > When I change the dialect to org.hibernate.dialect.GenericDialect the code works again > with EJB3RC1+RC2. This means > 1, Ingres supports paged queries > 2. The dialect org.hibernate.dialect.IngresDialect properly managed paged queries in > EJB3Beta1 > 3. The dialect org.hibernate.dialect.IngresDialect does not handle this correct anymore. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HBX-4) fetch statements not usable with Hibern8 IDE

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-4?page=com.... ] Steve Ebersole closed HBX-4. ---------------------------- Closing stale resolved issues > fetch statements not usable with Hibern8 IDE > -------------------------------------------- > > Key: HBX-4 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-4 > Project: Hibernate Tools > Issue Type: Improvement > Components: consoleconfiguration > Affects Versions: 2.1 > Environment: Hibernate 2.1.2, hibernate-extensions-2.0.2 > Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_03-b02) > Reporter: Will Iverson > Fix For: 3.1beta3 > > > When using a fetch (or certain other commands) within the Hibern8 IDE, the error: > fetch may not be used with scroll() or iterate() > is returned. I can think of a couple of different solutions for detecting the best session method, from a menu option, to a pref, to guessing the best based on the statement to just looking for that particular error and retrying the statement if that particular error is returned. > My first guess would be to go for the statement retry, as that would be more or less seamless to the user...? -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-917) Make it configurable to Throw Exception when resultset for query > max result

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-917?page=co... ] Steve Ebersole closed HHH-917. ------------------------------ Closing stale resolved issues > Make it configurable to Throw Exception when resultset for query > max result > ----------------------------------------------------------------------------- > > Key: HHH-917 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-917 > Project: Hibernate Core > Issue Type: New Feature > Reporter: Nico De Groote > > It would be nice to configure in hibernate to throw an exception whenever the nr of records returned > max results instead of just returning the max result number of records. By default do not throw an exception. > This implies to first perform a select count(*) query before proceeding to perform the actual query. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1035) AS clause should be optional and asked to Dialect

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1035?page=c... ] Steve Ebersole closed HHH-1035. ------------------------------- Closing stale resolved issues > AS clause should be optional and asked to Dialect > ------------------------------------------------- > > Key: HHH-1035 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1035 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.1 rc 1 > Environment: Any version, CTSQL database > Reporter: Aimar Tellitu > Assignee: Steve Ebersole > > I'm implementing a new Dialect for a non very popular DB, CTSQL of TransTOOLs S.A. > The problem is that for this Database, one SELECT like this has syntax errors: > select this_.state AS state0_, this_.sname AS sname0_0_ from states this_ > In this database sql syntax, AS clause isn't included and the correct SELECT should be: > select this_.state state0_, this_.sname sname0_0_ from states this_ > I have check the "American National Standard X3.135-1992" and I have seen that AS > clause is optional. Oddly, in many other Database the AS clause is mandatory. So, I guess > that this problem should be fixed adding one method in org.hibernate.dialect.Dialect to > determine if the AS clause should be added or not to the SELECT. > Thank you. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-184) dialects with theta-style outer joins

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-184?page=co... ] Steve Ebersole closed HHH-184. ------------------------------ Closing stale resolved issues > dialects with theta-style outer joins > ------------------------------------- > > Key: HHH-184 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-184 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.0 beta 4 > Reporter: Gavin King > Assignee: Steve Ebersole > > Currently, some queries are broken using the AST parser with dialects with theta-style outer joins. -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-1117) Incorrect org.hibernate.jdbc.ConnectionManager.isAggressiveRelease()

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1117?page=c... ] Steve Ebersole closed HHH-1117. ------------------------------- Closing stale resolved issues > Incorrect org.hibernate.jdbc.ConnectionManager.isAggressiveRelease() > -------------------------------------------------------------------- > > Key: HHH-1117 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1117 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1 rc2 > Environment: Hibernate 3.1 rc2 > Reporter: Adamansky Anton > Assignee: Steve Ebersole > Priority: Critical > > Hibernate is aggressively releases connections > in the following invironment: > hibernate.connection.release_mode=after_transaction > hibernate.connection.autocommit=false & connection.getAutoCommit() == false > But accourdingly to javadoc org.hibernate.jdbc.ConnectionManager.isAggressiveRelease() > Connections will be aggresivelly released after each statement if either: > 1) The defined release-mode is {@link ConnectionReleaseMode#AFTER_STATEMENT}; > 2) The defined release-mode is {@link ConnectionReleaseMode#AFTER_TRANSACTION} > Hibernate fails the case 2) > I've looked into code (), and found > org.hibernate.jdbc.ConnectionManager.isAggressiveRelease() { > .... > return releaseMode == ConnectionReleaseMode.AFTER_STATEMENT || > ( releaseMode != ConnectionReleaseMode.AFTER_TRANSACTION && inAutoCommitState ); > } > but, it should be: > org.hibernate.jdbc.ConnectionManager.isAggressiveRelease() { > .... > return releaseMode == ConnectionReleaseMode.AFTER_STATEMENT || > ( releaseMode == ConnectionReleaseMode.AFTER_TRANSACTION && inAutoCommitState ); > } > Anton -- 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

15 years, 1 month

1
0
0 / 0

[Hibernate-JIRA] Closed: (HHH-837) ReflectHelper#classForName should not catch Exception

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-837?page=co... ] Steve Ebersole closed HHH-837. ------------------------------ Closing stale resolved issues > ReflectHelper#classForName should not catch Exception > ----------------------------------------------------- > > Key: HHH-837 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-837 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Steven Devijver > Priority: Minor > > The classForName method in ReflectHelper should not catch Exception. Class loaders can throw other exceptions like LinkageError that should not be catched by Hibernate. Catching ClassNotFoundException is more appropriate. -- 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

15 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2011