November 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-957) SubqueryExpression throws ClassCastException on DetachedCriteria subqueries

by Thomas Goorden (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-957?page=co... ] Thomas Goorden commented on HHH-957: ------------------------------------ And still not fixed in 3.2... Also, it doesn't seem like a minor bug, people are obviously running into this quite a bit. > SubqueryExpression throws ClassCastException on DetachedCriteria subqueries > --------------------------------------------------------------------------- > > Key: HHH-957 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-957 > Project: Hibernate3 > Type: Bug > Versions: 3.0.5 > Environment: Oracle 9i, but probably not DB specific. > Reporter: Rob MacGrogan > Priority: Minor > Attachments: SubqueryExpression.java, SubqueryExpression.java > > > The toSqlString() method in SubqueryExpression contains a line that casts a Criteria object to CriteriaImpl in order to call the getSession() method. However, if DetachedCriteria is used as a subquery in a Criteria query, the underlying Criteria object will be CriteriaImpl.Subcriteria, thus a ClassCastException will be thrown. > I have created a bug fix. Add the following method to SubqueryExpression: > private SessionImpl getSessionImpl(Criteria criteria) { > SessionImpl session = null; > if (criteria instanceof CriteriaImpl) { > CriteriaImpl impl = (CriteriaImpl)criteria; > session = impl.getSession(); > } > else if (criteria instanceof CriteriaImpl.Subcriteria){ > CriteriaImpl.Subcriteria sub = (CriteriaImpl.Subcriteria)criteria; > //Alert! Recursive call here! > session = getSessionImpl(sub.getParent()); > } > return session; > } > And then replace the offending line in toSqlString() with a call to the new method. > Attached is SubqueryExpression with proposed changes in place. -- 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

19 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1276) Add outer join support to Criteria API

by Jan Heger (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1276?page=c... ] Jan Heger commented on HHH-1276: -------------------------------- Is there a reason, why this is not implemented in DetachedCriteria (CriteriaSpecification)? I'm pretty new to Hibernate but was looking for exactly this feature. Took me a while to realize that I can not use it, since it's missing in the CriteriaSpecification interface. > Add outer join support to Criteria API > -------------------------------------- > > Key: HHH-1276 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1276 > Project: Hibernate3 > Type: Patch > Components: core > Versions: 3.1 > Reporter: Jeremy Haile > Attachments: patch.txt > > > Here's a patch that allows users to specify a joinType when calling createCriteria and createAlias on the Criteria interface. This allows you to specify outer joins when creating Criteria. If you have any questions or see anything I missed - let me know. I have tested and am currently using the patch with no problems. -- 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

19 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2259) autoflush and autoclose not longer occur in JTA environment with hibernate 3.2

by Ulrich Winter (JIRA)

autoflush and autoclose not longer occur in JTA environment with hibernate 3.2 ------------------------------------------------------------------------------ Key: HHH-2259 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2259 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga, 3.2.1 Environment: jboss 4.0.5 Reporter: Ulrich Winter In a setup using JTASessionContext flush() and close() should occur automatically at the end of the transaction. This works with hibernate 3.0.5 but does not with hibernate 3.2.0-ga and 3.2.1-ga. Setup: hibernate.transaction.manager_lookup_class=org.hibernate.transaction.JBossTransactionManagerLookup hibernate.current_session_context_class=org.hibernate.context.JTASessionContext hibernate.transaction.flush_before_completion=true hibernate.transaction.auto_close_session=true Usage: public void doSomeWork() throws Exception { TransactionManager tm = (TransactionManager) Locator.lookup("java:/TransactionManager"); tm.begin(); Session session = sf.getCurrentSession(); PersistentObject data = new PersistentObject (); data.setXYZ("xyz"); session.save(data); tm.commit(); } Symptom: no inserts/updates/deletes, only "select xxx.nextval()" occur to the database. -- 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

19 years, 4 months

2
4
0 / 0

[Hibernate-JIRA] Commented: (HHH-1853) CREATE SCHEMA inside database-object need to execute before tables are created

by Mattias Jiderhamn (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853?page=c... ] Mattias Jiderhamn commented on HHH-1853: ---------------------------------------- As of Hibernate 3.2.1 the workaround mentioned above does no longer work, since a call to buildSettings() is introduced in org.hibernate.cfg.Configuration.generateSchemaUpdateScript(). Since settings have already been build, Spring will throw "No local DataSource found for configuration - dataSource property must be set on LocalSessionFactoryBean" from its LocalDataSourceConnectionProvider. Suddenly this moves from being a "Minor" problem to a "Major", since we cannot run our tests with 3.2.1. > CREATE SCHEMA inside database-object need to execute before tables are created > ------------------------------------------------------------------------------ > > Key: HHH-1853 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1853 > Project: Hibernate3 > Type: Improvement > Versions: 3.1.3 > Environment: hsqldb 1.8.0 > Reporter: Mattias Jiderhamn > Priority: Minor > > > In order to have Hibernate create database schemas for hsqldb, you have to insert a <database-object> in your mapping file (http://forums.hibernate.org/viewtopic.php?p=2305138). Problem is, all the database-object statements are executed after the tables are created, so tables in non-default schemas will not be created. To get around this, you have to first use Configuration.generateSchemaCreationScript() to get the schemas, and then Configuration.generateSchemaUpdateScript() to get the tables inside the schemas. > (This is a bit problematic when using Springs LocalSessionFactoryBean) -- 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

19 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2238) SQLQuery executeUpdate doesn't respect Query.setFlushMode()

by Tim Downey (JIRA)

SQLQuery executeUpdate doesn't respect Query.setFlushMode() ----------------------------------------------------------- Key: HHH-2238 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2238 Project: Hibernate3 Type: Bug Versions: 3.2.0.cr5 Environment: Windows/Oracle 10g Reporter: Tim Downey Priority: Minor Setting the flush mode manual on a SQLQuery is not respected when executeUpdate() is called. Under a standard Query, a call to before() is made prior to running executeUpdate(). The call to before() handles the query specific flush mode. This same behavior seems necessary for SQLQuery. Here is a fix for SQLQuery#executeUpdate public int executeUpdate() throws HibernateException { Map namedParams = getNamedParams(); before(); try { return getSession().executeNativeUpdate(generateQuerySpecification( namedParams ), getQueryParameters( namedParams )); finally { after(); } } -- 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

19 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2250) Create an appropriate error message if Query.setEntity is passed a NULL value

by Jonas Maurus (JIRA)

Create an appropriate error message if Query.setEntity is passed a NULL value ----------------------------------------------------------------------------- Key: HHH-2250 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2250 Project: Hibernate3 Type: Improvement Components: query-hql Versions: 3.2.0.ga, 3.2.1 Reporter: Jonas Maurus Priority: Minor setEntity(xyz, null) ends in a NPE in SessionImpl.guessEntityName(). This previously came up as HHH-675. I just spent hours tracking this NPE in our application, then upgrading Hibernate because I thought it might be a Hibernate bug :-/. The offending line read: .setEntity("customer", user.getCustomer()) "user" being an entity managed by Hibernate with user.customer being a nullable ManyToOne-relation. The current mode of "crash-and-burn" really looks like a Hibernate bug and not like expected behavior. I'd like to recommend that setEntity() should explicitly check for null-values. -- 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

19 years, 4 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2246) No way to specify CACHE_PROVIDER_CONFIG in HibernateServiceMBean

by amit bhayani (JIRA)

No way to specify CACHE_PROVIDER_CONFIG in HibernateServiceMBean ---------------------------------------------------------------- Key: HHH-2246 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2246 Project: Hibernate3 Type: New Feature Components: core Versions: 3.2.1 Reporter: amit bhayani HibernateServiceMBean doesn't have any attribute to specify hibernate.cache.provider_configuration_file_resource_path. For example if user makes use of EhCache, he/she has to fall back on default implementation of EhCache to find ehcache.xml file. -- 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

19 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2242) Consider Allowing Optimistic Lock Strategies other than 'Version' with joined-subclass

by Phillip Tornroth (JIRA)

Consider Allowing Optimistic Lock Strategies other than 'Version' with joined-subclass -------------------------------------------------------------------------------------- Key: HHH-2242 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2242 Project: Hibernate3 Type: Improvement Components: documentation, core Versions: 3.2.0.ga Reporter: Phillip Tornroth Priority: Minor The JoinedSubclassEntityPersister class explicitly disallows mapping joined-subclasses whenever an optimistic locking strategy of other than 'version' is used. It would be very useful to choose an optimistic locking strategy independent of an inheritance mapping strategy. In my case, I'm using 'none' for legacy reasons. If there's a good reason for continuing to enforce this constraint, it would be very helpful to document it in the hibernate reference. Thanks in advance... -- 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

19 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2253) query of attributes that are Collections of Values and arrays fail

by Jaideep Vasudevan (JIRA)

query of attributes that are Collections of Values and arrays fail ------------------------------------------------------------------ Key: HHH-2253 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2253 Project: Hibernate3 Type: New Feature Components: query-hql Versions: 3.1.2 Environment: oracle 10g Reporter: Jaideep Vasudevan The following query to return the attribute "address" that is a collection or an array throws an exception. select r.Id, r.address from Foo r where r.Id in (:ids) order by r.Id org.hibernate.QueryException: not an entity [select r.Id, r.address from com.cisco.nm.model.enum.Foo r where r.Id in (:ids) order by r.Id] at org.hibernate.hql.ast.tree.FromElementType.renderIdentifierSelect(FromElementType.java:143) at org.hibernate.hql.ast.tree.FromElement.renderIdentifierSelect(FromElement.java:167) at org.hibernate.hql.ast.tree.SelectClause.renderNonScalarIdentifiers(SelectClause.java:398) thanks, jaideep -- 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

19 years, 4 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2243) Statement closing due to unprovoked rollback

by Theresa (JIRA)

Statement closing due to unprovoked rollback -------------------------------------------- Key: HHH-2243 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2243 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: postgresql, hibernate 3.1.3, and apache DBCP Reporter: Theresa Has there been a resolution to the issue described at http://opensource.atlassian.com/projects/hibernate/browse/HHH-876? I have seen closed statement errors sporadically occurring and I can't get it under control. Even when the last execution of the statement is successful in a recursive loop reusing the statement, I can still see this happen. The stack and code is below. I am very curious how the rollback is getting called. There are several more places in the code where this is occurring. It is odd that it only happens sporadically and I have only identified 2 places out of a couple of dozen that actually causes this to occur. **************CONFIG******************** <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 3.0//EN" "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"> <hibernate-configuration> <session-factory> <property name="hibernate.connection.driver_class">org.postgresql.Driver</property> <property name="hibernate.connection.password">password</property> <property name="hibernate.connection.url">jdbc:postgresql://localhost/myDB</property> <property name="hibernate.connection.username">user</property> <property name="hibernate.dialect">org.hibernate.dialect.PostgreSQLDialect</property> <property name="hibernate.transaction.factory_class ">org.hibernate.transaction.JDBCTransactionFactory</property> <property name="hibernate.current_session_context_class">thread</property> <property name="hibernate.connection.provider_class">org.hibernate.connection.DBCPConnectionProvider</property>  <property name="hibernate.dbcp.maxActive">3</property> <property name="hibernate.dbcp.maxIdle">3</property> <property name="hibernate.dbcp.max Wait">60000</property> <property name="hibernate.dbcp.whenExhaustedAction">1</property> <property name="hibernate.dbcp.ps.maxActive">3</property> <property name="hibernate.dbcp.ps.maxIdle">3</property> <property name="hibernate.dbcp.ps.maxWait">1000*20</property> <property name="hibernate.dbcp.ps.whenExhaustedAction">1</property> <property name="hibernate.connection.release_mode">after_transaction</property> <property name="hibernate.dbcp.poolPreparedStatements">true</property> </session-factory> </hibernate-configuration> ********************CODE************** private synchronized HashMap<Integer, LeadDeliveryPreferences> queryForPreferences() throws SQLException{ // we open a session because this quartz group seems to have an // issue retrieving the session on the first job execution Session hibSession = HibernateUtil.getSessionFactory().openSession(); hibSession.beginTransaction(); Connection conn = hibSession.connection(); HashMap<Integer, LeadDeliveryPreferences> allMap = new HashMap<Integer, LeadDeliveryPreferences>(); try{ PreparedStatement stmt = conn.prepareStatement(QUERY_ALL_PREF); ResultSet rs = stmt.executeQuery(); //Query for lead delivery preferences while(rs.next()){ LeadDeliveryPreferences lp = new LeadDeliveryPreferences(); lp.setCampaignID(rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID)); lp.setCronSchedule(rs.getString(LeadDeliveryPreferences.DB_CRON_SCHEDULE)); lp.setEmail(rs.getString(LeadDeliveryPreferences.DB_EMAIL)); lp.setDeliveryEnabled(rs.getBoolean(LeadDeliveryPreferences.DB_DELIVERY_ENABLED)); lp.setDeliveryTransformer(rs.getString(LeadDeliveryPreferences.DB_DELIVERY_TRANSFORMER)); lp.setReportEnabled(rs.getBoolean(LeadDeliveryPreferences.DB_REPORT_ENABLED)); lp.setReportType(rs.getString(LeadDeliveryPreferences.DB_REPORT_TYPE)); lp.setSource(rs.getString(LeadDeliveryPreferences.DB_SOURCE)); allMap.put(rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID), lp); log_.debug("Picked up schedule for campaign: " + rs.getInt(LeadDeliveryPreferences.DB_CAMPAIGN_ID)); } //prepare statement object for re-use //stmt.clearParameters(); //Query for crosswalk values Iterator it = allMap.keySet().iterator(); ArrayList<Integer> idList = new ArrayList<Integer>(); while(it.hasNext()){ idList.add((Integer)it.next()); } PreparedStatement stmt2 = conn.prepareStatement(QUERY_TRANSLATIONS); for(int i=0;i<idList.size();i++){ log_.debug("Getting crosswalk for --> " + idList.get(i)); stmt2.setInt(1,idList.get(i)); ResultSet rs2 = stmt2.executeQuery(); LeadDeliveryPreferences lp = allMap.get(idList.get(i)); while(rs2.next()){ LeadCrosswalk lc = new LeadCrosswalk(); log_.debug("got key --> " + rs2.getString(LeadCrosswalk.DB_NAME_COL_NM)); lc.setName(rs2.getString(LeadCrosswalk.DB_NAME_COL_NM)); lc.setIsMethod(rs2.getBoolean(LeadCrosswalk.DB_IS_METHOD_COL_NM)); lc.setNameTranslation(rs2.getString(LeadCrosswalk.DB_NAME_TRANSLATION_COL_NM)); lc.setIsRequired(rs2.getBoolean(LeadCrosswalk.DB_IS_REQUIRED_COL_NM)); lp.addCrosswalk(lc.getName(), lc); } // prepare statement object for re-use stmt2.clearParameters(); allMap.remove(idList.get(i)); allMap.put(idList.get(i), lp); } //Query for phone ranges PreparedStatement stmt3 = conn.prepareStatement(QUERY_PHONE_RANGES); for(int i=0;i<idList.size();i++){ stmt3.setInt(1, idList.get(i)); rs = stmt3.executeQuery(); LeadDeliveryPreferences lp = allMap.get(idList.get(i)); while(rs.next()){ LeadDeliveryClientPhoneRanges phoneRange = new LeadDeliveryClientPhoneRanges(); phoneRange.setLow(rs.getInt(LeadDeliveryClientPhoneRanges.DB_LOW)); phoneRange.setHigh(rs.getInt(LeadDeliveryClientPhoneRanges.DB_HIGH)); phoneRange.setLabel(rs.getString(LeadDeliveryClientPhoneRanges.DB_LABEL)); log_.debug("Added phone range " + phoneRange.getLabel()); lp.addPhoneRange(phoneRange); } allMap.remove(idList.get(i)); allMap.put(idList.get(i), lp); } hibSession.getTransaction().commit(); } catch(SQLException se){ hibSession.getTransaction().rollback(); log_.error("SQLException occured querying for crosswalk", se); RuntimeErrorEmailHelper.addMessage("Error creating cron trigger"); throw se; } return allMap; } ****************STACK****************** 2006-11-15 13:56:02,892 [DefaultQuartzScheduler_Worker-8] DEBUG leads.delivery.LeadDeliveryPreferencesService - Getting crosswalk for --> 200 2006-11-15 13:56:02,899 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.transaction.JDBCTransaction - rollback 2006-11-15 13:56:02,912 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.transaction.JDBCTransaction - rolled back JDBC Connection 2006-11-15 13:56:02,912 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.jdbc.JDBCContext - after transaction completion 2006-11-15 13:56:02,912 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.jdbc.ConnectionManager - aggressively releasing JDBC connection 2006-11-15 13:56:02,912 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.jdbc.ConnectionManager - releasing JDBC connection [ (open PreparedStatements: 0, globally: 1) (open ResultSets: 0, globally: 0)] 2006-11-15 13:56:02,913 [DefaultQuartzScheduler_Worker-8] INFO hibernate.connection.DBCPConnectionProvider - active: 3 (max: 3) idle: 0(max: 3) 2006-11-15 13:56:02,913 [DefaultQuartzScheduler_Worker-8] DEBUG hibernate.impl.SessionImpl - after transaction completion 2006-11-15 13:56:02,915 [DefaultQuartzScheduler_Worker-8] ERROR leads.delivery.LeadDeliveryPreferencesService - SQLException occured querying for crosswalk 2006-11-15 13:56:02,920 [DefaultQuartzScheduler_Worker-8] INFO quartz.core.JobRunShell - Job LEAD_PREFERENCES.PREFERENCES_UPDATE_JOB threw a JobExecutionException: org.quartz.JobExecutionException: org.postgresql.util.PSQLException: This statement has been closed. [See nested exception: org.postgresql.util.PSQLExcepti on: This statement has been closed.] at com.tippit.service.leads.delivery.LeadDeliveryPreferencesService.execute(LeadDeliveryPreferencesService.java:185) at org.quartz.core.JobRunShell.run(JobRunShell.java:195) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) * Nested Exception (Underlying Cause) --------------- org.postgresql.util.PSQLException: This statement has been closed. at org.postgresql.jdbc2.AbstractJdbc2Statement.checkClosed(AbstractJdbc2Statement.java:2308) at org.postgresql.jdbc2.AbstractJdbc2Statement.setInt(AbstractJdbc2Statement.java:1070) at org.apache.commons.dbcp.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:116) at org.apache.commons.dbcp.DelegatingPreparedStatement.setInt(DelegatingPreparedStatement.java:116) at com.tippit.service.leads.delivery.LeadDeliveryPreferencesService.queryForPreferences(LeadDeliveryPreferencesService.java:116) at com.tippit.service.leads.delivery.LeadDeliveryPreferencesService.load(LeadDeliveryPreferencesService.java:61) at com.tippit.service.leads.delivery.LeadDeliveryPreferencesService.execute(LeadDeliveryPreferencesService.java:181) at org.quartz.core.JobRunShell.run(JobRunShell.java:195) at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:520) -- 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

19 years, 4 months

2
3
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 November 2006