Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-12-19 13:46:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-570 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-570 Summary: EHCache Optional? Type: Bug Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 final Assignee: Reporter: Prasad Khandekar Created: Fri, 19 Dec 2003 7:45 AM Updated: Fri, 19 Dec 2003 7:45 AM Environment: Windows 2000, JDK 1.4, Tomcat 4.1.24, Oracle 8i Description: The readme.txt file from Hibernate 2.1 final source archive says that the ehcache.jar file is optional. But the default settings makes the presence of this jar file mandetory. The code in buildSettings of SettingsFactory class defaults to ehcache provider and throws an exception. (It is possible to override this by setting use_query_cache property to false in hibernate.properties.) Is this jar is really necessary? If yes please provide an indication for the same. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-19 13:36:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-569 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-569 Summary: SchemaExport generates incorrect schema separator for MySQL Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: toolset Versions: 2.1.1 Assignee: Reporter: Jos Annevelink Created: Fri, 19 Dec 2003 7:35 AM Updated: Fri, 19 Dec 2003 7:35 AM Description: While everything worked ok on 2.0.3 I saw incorrect DDL/SQL being generated while trying to switch my application to 2.1.1 The DDL generated reads "... dbname_tablename ..." whereas it should read "... dbname.tablename ..." (dot for separator instead of underscore). It seems a method MySQLDialect.getSchemaSeparator() was added which returns a '_' instead of a '.'. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-18 16:26:09
|
The following issue has been updated:
Updater: Adrien (mailto:hib...@sa...)
Date: Thu, 18 Dec 2003 10:25 AM
Comment:
The same two modifications as a patch.
Adrien
Changes:
Attachment changed to HB-534_patch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-534&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-534
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-534
Summary: Table schema use in DatabaseMetadata
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1 beta 4
Assignee:
Reporter: Adrien
Created: Tue, 9 Dec 2003 10:55 AM
Updated: Thu, 18 Dec 2003 10:25 AM
Environment: Hibernate 2.1 beta 4, Oracle 8i
Description:
When using SchemaUpdate, the DatabaseMetaData.getTableMetadata() looks for a table with the correct table name in any database schema and it take the first one it found. This behavior is uncorrect if I have a table existing in different schemas.
The correct behavior would be to first look in the schema with the login name and after in any schema.
user1.article
user2.article
I connected whith user2, DatabaseMetaData should first look for user2.article, then if not found to %.article.
Adrien
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-18 10:43:11
|
Message:
The following issue has been closed.
Resolver: Christian Bauer
Date: Thu, 18 Dec 2003 4:43 AM
Added to community area.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-568
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-568
Summary: Link OSCache and Hibernate from documentation
Type: Improvement
Status: Closed
Priority: Minor
Resolution: FIXED
Project: Hibernate2
Components:
core
Versions:
2.2 alpha
Assignee:
Reporter: Mathias Bogaert
Created: Thu, 18 Dec 2003 4:31 AM
Updated: Thu, 18 Dec 2003 4:43 AM
Description:
The documentation on how to integrate OSCache with Hibernate is available here: http://www.opensymphony.com/oscache/hibernate.html.
Please link this from the documentation or website.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-18 10:32:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-568 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-568 Summary: Link OSCache and Hibernate from documentation Type: Improvement Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.2 alpha Assignee: Reporter: Mathias Bogaert Created: Thu, 18 Dec 2003 4:31 AM Updated: Thu, 18 Dec 2003 4:31 AM Description: The documentation on how to integrate OSCache with Hibernate is available here: http://www.opensymphony.com/oscache/hibernate.html. Please link this from the documentation or website. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-18 08:20:08
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 18 Dec 2003 2:19 AM
Body:
What do you mean "native type" ? Do you mean primitive type? If so, I don't see why we should be allowed to assign a null value to a primitive...
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-567
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-567
Summary: NullPointerException when using "select new" on constructor with native types
Type: Bug
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1.1
Assignee:
Reporter: Shorn Tolley
Created: Wed, 17 Dec 2003 7:38 PM
Updated: Thu, 18 Dec 2003 2:19 AM
Environment: Win2k, JDK 1.4.2, HB 2.1.1
Description:
When my DTO object that I am "Select new"'ing into has a constructor that takes native types, I get the error attached.
If my DTO has a ctor which takes wrapper types, the code works.
If it has both, then Hibernate seems to prefer the native version, and I get the error.
I tried implementing the native-type ctor in two ways, using the "this" keyword to delegate to the wrapper-type ctor or with direct calls to the setter methods on the DTO. Didn't seem to make any difference.
Exception:
[junit] Testcase: testFindDocumentsByCaseDTOsWithEmptyCriteria(nrm.clas.persistence.document.test.DocumentPersistenceManagerTest): Caused an ERROR
[junit] Error finding documents by case
[junit] nrm.clas.persistence.PersistenceLayerException: Error finding documents by case
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
[junit] at nrm.clas.ExceptionUtil.instantiateException(ExceptionUtil.java:89)
[junit] at nrm.clas.ExceptionUtil.createNestedException(ExceptionUtil.java:127)
[junit] at nrm.clas.ExceptionUtil.createPersistenceLayerException(ExceptionUtil.java:312)
[junit] at nrm.clas.ExceptionUtil.createPersistenceLayerException(ExceptionUtil.java:291)
[junit] at nrm.clas.persistence.document.DocumentPersistenceManagerImpl.findDocumentsByCaseDTOs(DocumentPersistenceManagerImpl.java:162)
[junit] at nrm.clas.persistence.document.test.DocumentPersistenceManagerTest.testFindDocumentsByCaseDTOsWithEmptyCriteria(DocumentPersistenceManagerTest.java:45)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
[junit] at nrm.clas.test.ClasTestCase.run(ClasTestCase.java:508)
[junit] Caused by: nrm.clas.common.persistence.PersistenceException: find
[junit] at nrm.clas.persistence.BasePersistenceManagerImpl.handleError(BasePersistenceManagerImpl.java:97)
[junit] at nrm.clas.persistence.BasePersistenceManagerImpl.handleError(BasePersistenceManagerImpl.java:116)
[junit] at nrm.clas.persistence.BasePersistenceManagerImpl.find(BasePersistenceManagerImpl.java:365)
[junit] at nrm.clas.persistence.document.DocumentPersistenceManagerImpl.findDocumentsByCaseDTOs(DocumentPersistenceManagerImpl.java:159)
[junit] ... 16 more
[junit] Caused by: net.sf.hibernate.QueryException: could not instantiate: class nrm.clas.dto.document.CaseDocumentDTO
[junit] at net.sf.hibernate.hql.QueryTranslator.getResultColumnOrRow(QueryTranslator.java:993)
[junit] at net.sf.hibernate.loader.Loader.doQuery(Loader.java:221)
[junit] at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:132)
[junit] at net.sf.hibernate.loader.Loader.doList(Loader.java:949)
[junit] at net.sf.hibernate.loader.Loader.list(Loader.java:940)
[junit] at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:833)
[junit] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1475)
[junit] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1454)
[junit] at nrm.clas.persistence.BasePersistenceManagerImpl.find(BasePersistenceManagerImpl.java:359)
[junit] ... 17 more
[junit] Caused by: java.lang.NullPointerException
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
[junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
[junit] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
[junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
[junit] at net.sf.hibernate.hql.QueryTranslator.getResultColumnOrRow(QueryTranslator.java:990)
[junit] ... 25 more
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-18 01:39:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-567 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-567 Summary: NullPointerException when using "select new" on constructor with native types Type: Bug Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1.1 Assignee: Reporter: Shorn Tolley Created: Wed, 17 Dec 2003 7:38 PM Updated: Wed, 17 Dec 2003 7:38 PM Environment: Win2k, JDK 1.4.2, HB 2.1.1 Description: When my DTO object that I am "Select new"'ing into has a constructor that takes native types, I get the error attached. If my DTO has a ctor which takes wrapper types, the code works. If it has both, then Hibernate seems to prefer the native version, and I get the error. I tried implementing the native-type ctor in two ways, using the "this" keyword to delegate to the wrapper-type ctor or with direct calls to the setter methods on the DTO. Didn't seem to make any difference. Exception: [junit] Testcase: testFindDocumentsByCaseDTOsWithEmptyCriteria(nrm.clas.persistence.document.test.DocumentPersistenceManagerTest): Caused an ERROR [junit] Error finding documents by case [junit] nrm.clas.persistence.PersistenceLayerException: Error finding documents by case [junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [junit] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274) [junit] at nrm.clas.ExceptionUtil.instantiateException(ExceptionUtil.java:89) [junit] at nrm.clas.ExceptionUtil.createNestedException(ExceptionUtil.java:127) [junit] at nrm.clas.ExceptionUtil.createPersistenceLayerException(ExceptionUtil.java:312) [junit] at nrm.clas.ExceptionUtil.createPersistenceLayerException(ExceptionUtil.java:291) [junit] at nrm.clas.persistence.document.DocumentPersistenceManagerImpl.findDocumentsByCaseDTOs(DocumentPersistenceManagerImpl.java:162) [junit] at nrm.clas.persistence.document.test.DocumentPersistenceManagerTest.testFindDocumentsByCaseDTOsWithEmptyCriteria(DocumentPersistenceManagerTest.java:45) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at nrm.clas.test.ClasTestCase.run(ClasTestCase.java:508) [junit] Caused by: nrm.clas.common.persistence.PersistenceException: find [junit] at nrm.clas.persistence.BasePersistenceManagerImpl.handleError(BasePersistenceManagerImpl.java:97) [junit] at nrm.clas.persistence.BasePersistenceManagerImpl.handleError(BasePersistenceManagerImpl.java:116) [junit] at nrm.clas.persistence.BasePersistenceManagerImpl.find(BasePersistenceManagerImpl.java:365) [junit] at nrm.clas.persistence.document.DocumentPersistenceManagerImpl.findDocumentsByCaseDTOs(DocumentPersistenceManagerImpl.java:159) [junit] ... 16 more [junit] Caused by: net.sf.hibernate.QueryException: could not instantiate: class nrm.clas.dto.document.CaseDocumentDTO [junit] at net.sf.hibernate.hql.QueryTranslator.getResultColumnOrRow(QueryTranslator.java:993) [junit] at net.sf.hibernate.loader.Loader.doQuery(Loader.java:221) [junit] at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:132) [junit] at net.sf.hibernate.loader.Loader.doList(Loader.java:949) [junit] at net.sf.hibernate.loader.Loader.list(Loader.java:940) [junit] at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:833) [junit] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1475) [junit] at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1454) [junit] at nrm.clas.persistence.BasePersistenceManagerImpl.find(BasePersistenceManagerImpl.java:359) [junit] ... 17 more [junit] Caused by: java.lang.NullPointerException [junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) [junit] at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) [junit] at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) [junit] at java.lang.reflect.Constructor.newInstance(Constructor.java:274) [junit] at net.sf.hibernate.hql.QueryTranslator.getResultColumnOrRow(QueryTranslator.java:990) [junit] ... 25 more --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 17:30:08
|
The following issue has been updated:
Updater: William Drai (mailto:wil...@fr...)
Date: Wed, 17 Dec 2003 11:28 AM
Comment:
HibernateService.java and HibernateServiceMBean.java
Changes:
Attachment changed to jmx.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-566&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-566
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-566
Summary: Simple patch for HB-560 and HB-561
Type: Patch
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 11:27 AM
Updated: Wed, 17 Dec 2003 11:28 AM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 17:28:08
|
The following issue has been updated:
Updater: William Drai (mailto:wil...@fr...)
Date: Wed, 17 Dec 2003 11:28 AM
Comment:
Configuration.java and Environment.java
Changes:
Attachment changed to cfg.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-566&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-566
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-566
Summary: Simple patch for HB-560 and HB-561
Type: Patch
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 11:27 AM
Updated: Wed, 17 Dec 2003 11:28 AM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 17:28:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-566 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-566 Summary: Simple patch for HB-560 and HB-561 Type: Patch Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 Assignee: Reporter: William Drai Created: Wed, 17 Dec 2003 11:27 AM Updated: Wed, 17 Dec 2003 11:27 AM Description: --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 16:45:09
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Wed, 17 Dec 2003 10:44 AM
This is a bug in your build of HSQL. Use the build in Hibernate CVS.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-565
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-565
Summary: HSQLDB Select Query Doesn't work with Dialect
Type: Bug
Status: Closed
Priority: Critical
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0 final
Assignee:
Reporter: Deepak Singh
Created: Wed, 17 Dec 2003 10:39 AM
Updated: Wed, 17 Dec 2003 10:44 AM
Environment: Webserver: Tomcat 5.1
DB: HSQL 1.7.2 Aplha T and also tried on HSQL 1.7.1 on
OS: Windows XP
JDK:1.4.1_01-b01
Hibernate Version: Hibernate 2 final
Description:
This happened when I tried to use:
hibernate.dialect=net.sf.hibernate.dialect.HSQLDialect
Wrong data type: TOP m in statement [select top ? user0_.userName as userName, user0_.password as password from USER user0_ where (user0_.userName=? )]
And if I don't use a Dialect the Application works fine.
Caused by: net.sf.hibernate.JDBCException: Could not execute query
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1476)
at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:45)
at com.rhi.bob.hb.db.GenericDao.doQuery(GenericDao.java:456)
at com.rhi.bob.hb.db.GenericDao.find(GenericDao.java:333)
... 33 more
Caused by: java.sql.SQLException: Wrong data type: TOP m in statement [select top ? user0_.userName as userName, user0_.password as password from USER user0_ where (user0_.userName=? )]
at org.hsqldb.jdbcDriver.throwError(Unknown Source)
at org.hsqldb.jdbcPreparedStatement.<init>(Unknown Source)
at org.hsqldb.jdbcConnection.prepareStatement(Unknown Source)
at net.sf.hibernate.impl.BatcherImpl.getPreparedStatement(BatcherImpl.java:233)
at net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:61)
at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:699)
at net.sf.hibernate.loader.Loader.doQuery(Loader.java:180)
at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:128)
at net.sf.hibernate.loader.Loader.list(Loader.java:918)
at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:983)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1473)
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 16:40:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-565 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-565 Summary: HSQLDB Select Query Doesn't work with Dialect Type: Bug Status: Unassigned Priority: Critical Project: Hibernate2 Components: core Versions: 2.0 final Assignee: Reporter: Deepak Singh Created: Wed, 17 Dec 2003 10:39 AM Updated: Wed, 17 Dec 2003 10:39 AM Environment: Webserver: Tomcat 5.1 DB: HSQL 1.7.2 Aplha T and also tried on HSQL 1.7.1 on OS: Windows XP JDK:1.4.1_01-b01 Hibernate Version: Hibernate 2 final Description: This happened when I tried to use: hibernate.dialect=net.sf.hibernate.dialect.HSQLDialect Wrong data type: TOP m in statement [select top ? user0_.userName as userName, user0_.password as password from USER user0_ where (user0_.userName=? )] And if I don't use a Dialect the Application works fine. Caused by: net.sf.hibernate.JDBCException: Could not execute query at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1476) at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:45) at com.rhi.bob.hb.db.GenericDao.doQuery(GenericDao.java:456) at com.rhi.bob.hb.db.GenericDao.find(GenericDao.java:333) ... 33 more Caused by: java.sql.SQLException: Wrong data type: TOP m in statement [select top ? user0_.userName as userName, user0_.password as password from USER user0_ where (user0_.userName=? )] at org.hsqldb.jdbcDriver.throwError(Unknown Source) at org.hsqldb.jdbcPreparedStatement.<init>(Unknown Source) at org.hsqldb.jdbcConnection.prepareStatement(Unknown Source) at net.sf.hibernate.impl.BatcherImpl.getPreparedStatement(BatcherImpl.java:233) at net.sf.hibernate.impl.BatcherImpl.prepareQueryStatement(BatcherImpl.java:61) at net.sf.hibernate.loader.Loader.prepareQueryStatement(Loader.java:699) at net.sf.hibernate.loader.Loader.doQuery(Loader.java:180) at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:128) at net.sf.hibernate.loader.Loader.list(Loader.java:918) at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:983) at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1473) --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 14:43:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-564 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-564 Summary: Compile Queries Type: New Feature Status: Unassigned Priority: Major Project: Hibernate2 Components: toolset Assignee: Reporter: Ted Tollefson Created: Wed, 17 Dec 2003 8:42 AM Updated: Wed, 17 Dec 2003 8:42 AM Description: It should be possible to "compile" the Hibernate queries. It should be possible to detect at compile-time a syntax error in a query that has been defined in the xml configuration files. I envision a tool that could start the "compile" from an Ant script. It check the syntax of all the user defined queries and report any errors. This should not be too difficult to do because Hibernate must already have query parsing functionality. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 14:16:08
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Wed, 17 Dec 2003 8:15 AM
This is intended, the only way to respect the semantics of "or". If you want some other behavior, use an explicit join the in from clause.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-563
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-563
Summary: Bad join in HQL queries
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee: Gavin King
Reporter: William Drai
Created: Wed, 17 Dec 2003 8:08 AM
Updated: Wed, 17 Dec 2003 8:15 AM
Description:
I have the following (simplified) mapping :
<class name="Cat" table="CAT_T">
<id .. />
<many-to-one name="sex" class="Sex" column="sex_id" />
<many-to-one name="color" class="Color" column="color_id" />
</class>
<class name="Sex" table="SEX_T">
<id .. />
<property name="name" type="string" />
</class>
<class name="Color" table="COLOR_T">
<id .. />
<property name="name" type="string" />
</class>
The HQL query :
select cat
from cat in class Cat
where cat.sex.name = 'female'
or cat.color.name = 'black'
is translated to something like :
select cat
from CAT_T cat, SEX_T sex, COLOR_T color
where
(cat.sex_id = sex.id and sex.name = 'female')
or
(cat.color_id = color.id and color.name = 'black')
That means that I get a cartesian product of
all cats with sex female by all colors
and all cats with color black by all sexes.
That is a lot more results than the female or black cats.
What I expected was :
select cat
from CAT_T cat, SEX_T sex, COLOR_T color
where
cat.sex_id = sex.id
and cat.color_id = color.id
and (sex.name = 'female' or color.name = 'black')
I don't know whether this is really a bug or this is wanted for
some reason but it seems rather strange.
William
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 14:10:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-563 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-563 Summary: Bad join in HQL queries Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 Assignee: Reporter: William Drai Created: Wed, 17 Dec 2003 8:08 AM Updated: Wed, 17 Dec 2003 8:08 AM Description: I have the following (simplified) mapping : <class name="Cat" table="CAT_T"> <id .. /> <many-to-one name="sex" class="Sex" column="sex_id" /> <many-to-one name="color" class="Color" column="color_id" /> </class> <class name="Sex" table="SEX_T"> <id .. /> <property name="name" type="string" /> </class> <class name="Color" table="COLOR_T"> <id .. /> <property name="name" type="string" /> </class> The HQL query : select cat from cat in class Cat where cat.sex.name = 'female' or cat.color.name = 'black' is translated to something like : select cat from CAT_T cat, SEX_T sex, COLOR_T color where (cat.sex_id = sex.id and sex.name = 'female') or (cat.color_id = color.id and color.name = 'black') That means that I get a cartesian product of all cats with sex female by all colors and all cats with color black by all sexes. That is a lot more results than the female or black cats. What I expected was : select cat from CAT_T cat, SEX_T sex, COLOR_T color where cat.sex_id = sex.id and cat.color_id = color.id and (sex.name = 'female' or color.name = 'black') I don't know whether this is really a bug or this is wanted for some reason but it seems rather strange. William --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 13:51:08
|
The following issue has been updated:
Updater: William Drai (mailto:wil...@fr...)
Date: Wed, 17 Dec 2003 7:49 AM
Comment:
Patch for HibernateService and HibernateServiceMBean
Also contains the patch for issue HB-561
Changes:
Attachment changed to jmx.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-560&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-560
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-560
Summary: Caching configuration with same class mapped in many sessionFactories
Type: Improvement
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 6:01 AM
Updated: Wed, 17 Dec 2003 7:49 AM
Description:
I'm sorry to reopen this issue but I still have a small problem.
I have the same class mapped in three differents session factories to three different MySQL databases.
Everything works (now with EHCache) BUT I am not able to define different cache configurations for the three cache instances because the cache region name is the same (it is the class name).
This is also true for all cache providers.
Moreover I have not tried yet the replicated cache but I don't see how the replication could be able to identify the correct cache instance in the remote server if all three have the same region name.
For the moment I implemented a wrapper CacheProvider which just adds the session factory property 'cache.region_prefix' before the region name and added this property to the Hibernate JMX MBean.
It would be a lot easier to configure if this was directly configured in hibernate. This is really trivial and I hope it could be useful for other people.
Thanks.
William
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 13:49:09
|
The following issue has been updated:
Updater: William Drai (mailto:wil...@fr...)
Date: Wed, 17 Dec 2003 7:48 AM
Comment:
Patch for Configuration.java and Environment.java
Changes:
Attachment changed to cfg.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-560&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-560
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-560
Summary: Caching configuration with same class mapped in many sessionFactories
Type: Improvement
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 6:01 AM
Updated: Wed, 17 Dec 2003 7:48 AM
Description:
I'm sorry to reopen this issue but I still have a small problem.
I have the same class mapped in three differents session factories to three different MySQL databases.
Everything works (now with EHCache) BUT I am not able to define different cache configurations for the three cache instances because the cache region name is the same (it is the class name).
This is also true for all cache providers.
Moreover I have not tried yet the replicated cache but I don't see how the replication could be able to identify the correct cache instance in the remote server if all three have the same region name.
For the moment I implemented a wrapper CacheProvider which just adds the session factory property 'cache.region_prefix' before the region name and added this property to the Hibernate JMX MBean.
It would be a lot easier to configure if this was directly configured in hibernate. This is really trivial and I hope it could be useful for other people.
Thanks.
William
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 13:39:08
|
The following comment has been added to this issue:
Author: Tom Sedge
Created: Wed, 17 Dec 2003 7:39 AM
Body:
Fair enough. As I expected.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-562
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-562
Summary: Using Session.load(Class, Serializable) Proxy is of incorrect type
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Tom Sedge
Created: Wed, 17 Dec 2003 7:27 AM
Updated: Wed, 17 Dec 2003 7:39 AM
Environment: Windows 2000, Sun JDK
Description:
Possibly, this may be considered a feature rather than a bug.
Suppose I have two classes, say Product and Computer, where Computer extends Product. Both are proxied by Hibernate.
In a generic application I wish to load and step through all Products using Session.load(Product.class, <id>). If I use Session.load(Product.class, <Computer Id>), the Computer object is correctly loaded and wrapped in a Proxy. It behaves as a Computer.
However, the Proxy thinks it is wrapping a Product, not a Computer, because it uses the class requested. This means that Computer.class.isAssignableFrom(<proxy>.getClass()) fails.
I consider this a bug, even though I know Product.class has been requested. That's because for an unproxied object you get a Computer instance, not a Product, so the behaviour depends on whether the object is proxied.
P.S.: It is not possible for the generic application to know that it is about to load a Computer subclass, so it must rely on loading using Product.class, which works fine with unproxied classes.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 13:34:08
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Wed, 17 Dec 2003 7:32 AM
This is of course not a bug, since it is completely impossible to determine the concrete type w/o hitting the database. If you /do/ want to hit the database, use Session.get() instead of load(). This is all well-documented.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-562
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-562
Summary: Using Session.load(Class, Serializable) Proxy is of incorrect type
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Tom Sedge
Created: Wed, 17 Dec 2003 7:27 AM
Updated: Wed, 17 Dec 2003 7:32 AM
Environment: Windows 2000, Sun JDK
Description:
Possibly, this may be considered a feature rather than a bug.
Suppose I have two classes, say Product and Computer, where Computer extends Product. Both are proxied by Hibernate.
In a generic application I wish to load and step through all Products using Session.load(Product.class, <id>). If I use Session.load(Product.class, <Computer Id>), the Computer object is correctly loaded and wrapped in a Proxy. It behaves as a Computer.
However, the Proxy thinks it is wrapping a Product, not a Computer, because it uses the class requested. This means that Computer.class.isAssignableFrom(<proxy>.getClass()) fails.
I consider this a bug, even though I know Product.class has been requested. That's because for an unproxied object you get a Computer instance, not a Product, so the behaviour depends on whether the object is proxied.
P.S.: It is not possible for the generic application to know that it is about to load a Computer subclass, so it must rely on loading using Product.class, which works fine with unproxied classes.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 13:32:08
|
The following comment has been added to this issue:
Author: Tom Sedge
Created: Wed, 17 Dec 2003 7:31 AM
Body:
I should have also said that I'm not sure what could be done about this since we don't know what type the object is before it is unproxied.
But I still feel uncomfortable with this behaviour.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-562
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-562
Summary: Using Session.load(Class, Serializable) Proxy is of incorrect type
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.0.3
Assignee:
Reporter: Tom Sedge
Created: Wed, 17 Dec 2003 7:27 AM
Updated: Wed, 17 Dec 2003 7:31 AM
Environment: Windows 2000, Sun JDK
Description:
Possibly, this may be considered a feature rather than a bug.
Suppose I have two classes, say Product and Computer, where Computer extends Product. Both are proxied by Hibernate.
In a generic application I wish to load and step through all Products using Session.load(Product.class, <id>). If I use Session.load(Product.class, <Computer Id>), the Computer object is correctly loaded and wrapped in a Proxy. It behaves as a Computer.
However, the Proxy thinks it is wrapping a Product, not a Computer, because it uses the class requested. This means that Computer.class.isAssignableFrom(<proxy>.getClass()) fails.
I consider this a bug, even though I know Product.class has been requested. That's because for an unproxied object you get a Computer instance, not a Product, so the behaviour depends on whether the object is proxied.
P.S.: It is not possible for the generic application to know that it is about to load a Computer subclass, so it must rely on loading using Product.class, which works fine with unproxied classes.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 13:28:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-562 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-562 Summary: Using Session.load(Class, Serializable) Proxy is of incorrect type Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.0.3 Assignee: Reporter: Tom Sedge Created: Wed, 17 Dec 2003 7:27 AM Updated: Wed, 17 Dec 2003 7:27 AM Environment: Windows 2000, Sun JDK Description: Possibly, this may be considered a feature rather than a bug. Suppose I have two classes, say Product and Computer, where Computer extends Product. Both are proxied by Hibernate. In a generic application I wish to load and step through all Products using Session.load(Product.class, <id>). If I use Session.load(Product.class, <Computer Id>), the Computer object is correctly loaded and wrapped in a Proxy. It behaves as a Computer. However, the Proxy thinks it is wrapping a Product, not a Computer, because it uses the class requested. This means that Computer.class.isAssignableFrom(<proxy>.getClass()) fails. I consider this a bug, even though I know Product.class has been requested. That's because for an unproxied object you get a Computer instance, not a Product, so the behaviour depends on whether the object is proxied. P.S.: It is not possible for the generic application to know that it is about to load a Computer subclass, so it must rely on loading using Product.class, which works fine with unproxied classes. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 12:08:09
|
The following comment has been added to this issue:
Author: Gavin King
Created: Wed, 17 Dec 2003 6:07 AM
Body:
If you submit a patch, I will consider it.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-560
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-560
Summary: Caching configuration with same class mapped in many sessionFactories
Type: Improvement
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 6:01 AM
Updated: Wed, 17 Dec 2003 6:07 AM
Description:
I'm sorry to reopen this issue but I still have a small problem.
I have the same class mapped in three differents session factories to three different MySQL databases.
Everything works (now with EHCache) BUT I am not able to define different cache configurations for the three cache instances because the cache region name is the same (it is the class name).
This is also true for all cache providers.
Moreover I have not tried yet the replicated cache but I don't see how the replication could be able to identify the correct cache instance in the remote server if all three have the same region name.
For the moment I implemented a wrapper CacheProvider which just adds the session factory property 'cache.region_prefix' before the region name and added this property to the Hibernate JMX MBean.
It would be a lot easier to configure if this was directly configured in hibernate. This is really trivial and I hope it could be useful for other people.
Thanks.
William
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 12:08:08
|
The following comment has been added to this issue:
Author: Gavin King
Created: Wed, 17 Dec 2003 6:07 AM
Body:
Agreed. I will accept a patch for this.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-561
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-561
Summary: Add of sessionFactory evict methods to JMX MBean
Type: Improvement
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: William Drai
Created: Wed, 17 Dec 2003 6:06 AM
Updated: Wed, 17 Dec 2003 6:07 AM
Description:
It would be really useful for system administrators to be able to call the evictXXX methods of the sessionFactory from the JMX MBean, when the database has been manually updated.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-12-17 12:08:08
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-561 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-561 Summary: Add of sessionFactory evict methods to JMX MBean Type: Improvement Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 Assignee: Reporter: William Drai Created: Wed, 17 Dec 2003 6:06 AM Updated: Wed, 17 Dec 2003 6:06 AM Description: It would be really useful for system administrators to be able to call the evictXXX methods of the sessionFactory from the JMX MBean, when the database has been manually updated. --------------------------------------------------------------------- JIRA INFORMATION: 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.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-12-17 12:06:08
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Wed, 17 Dec 2003 6:05 AM
This is not a bug in Hibernate and if you use a decent driver for SQL Server, you will have no problems.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-559
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-559
Summary: SQLServer "can not re-read row data..." exception in one-to-many
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Project: Hibernate2
Components:
core
Versions:
2.1 final
Assignee:
Reporter: Bodo Junglas
Created: Wed, 17 Dec 2003 5:25 AM
Updated: Wed, 17 Dec 2003 6:05 AM
Environment: Windows 2000/XP, JBoss 3.2.3
Description:
PAttributedEntity has a non-lazy one-to-many relation to PAttributeInstance mapped as java.util.Set
PAttributedEntity has joined-subclasses (don't know if that is important here). If I load one of these subclasses from SQLServer using the Mircosoft JDBC driver I get:
12:14:06,706 DEBUG [SessionImpl] collection not cached
12:14:06,706 DEBUG [SessionImpl] done materializing entity [de.objectcode.canyon.persistent.instance.PProcessInstance#10]
12:14:06,706 DEBUG [SessionImpl] initializing non-lazy collections
12:14:06,706 DEBUG [SessionImpl] initializing collection [de.objectcode.canyon.persistent.instance.PAttributedEntity.attributesSet#10]
12:14:06,706 DEBUG [BatcherImpl] about to open: 0 open PreparedStatements, 0 open ResultSets
12:14:06,706 DEBUG [BatcherImpl] prepared statement get: select attributes0_.ATTRIBUTEINSTANCEID as ATTRIBUT1___, attributes0_.OWNERID as OWNERID__, attributes0
_.ATTRIBUTEINSTANCEID as ATTRIBUT1_0_, attributes0_.BOOLVALUE as BOOLVALUE0_, attributes0_.DATAVALUE as DATAVALUE0_, attributes0_.DBLVALUE as DBLVALUE0_, attrib
utes0_.INTVALUE as INTVALUE0_, attributes0_.STRVALUE as STRVALUE0_, attributes0_.OBJVALUE as OBJVALUE0_, attributes0_.TYPE as TYPE0_, attributes0_.NAME as NAME0
_ from PATTRIBUTEINSTANCES attributes0_ where attributes0_.OWNERID=?
12:14:06,706 DEBUG [BatcherImpl] preparing statement
12:14:06,706 DEBUG [LongType] binding '10' to parameter: 1
12:14:06,736 DEBUG [Loader] result set contains (possibly empty) collection: [de.objectcode.canyon.persistent.instance.PAttributedEntity.attributesSet#10]
12:14:06,736 DEBUG [SessionImpl] uninitialized collection: initializing
12:14:06,736 DEBUG [Loader] processing result set
12:14:06,736 INFO [STDOUT] >>>>>>>> ATTRIBUT1_0_ 3 ATTRIBUT1_0_ ATTRIBUT1_0_
12:14:06,736 DEBUG [LongType] returning '7' as column: ATTRIBUT1_0_
12:14:06,736 DEBUG [Loader] result row: 7
12:14:06,736 DEBUG [Loader] Initializing object from ResultSet: 7
12:14:06,736 DEBUG [Loader] Hydrating entity: de.objectcode.canyon.persistent.instance.PAttributeInstance#7
12:14:06,736 DEBUG [BooleanType] returning null as column: BOOLVALUE0_
12:14:06,736 DEBUG [TimestampType] returning null as column: DATAVALUE0_
12:14:06,736 DEBUG [DoubleType] returning null as column: DBLVALUE0_
12:14:06,736 DEBUG [IntegerType] returning null as column: INTVALUE0_
12:14:06,736 DEBUG [StringType] returning 'WorkFlowSink' as column: STRVALUE0_
12:14:06,736 DEBUG [IntegerType] returning '0' as column: TYPE0_
12:14:06,736 DEBUG [StringType] returning 'starterUserID' as column: NAME0_
12:14:06,736 INFO [STDOUT] >>>>>>>> OWNERID__ 2 OWNERID__ OWNERID__
12:14:06,736 DEBUG [JDBCExceptionReporter] SQL Exception
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]ResultSet can not re-read row data for column 2.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.base.BaseResultSet.validateColumnIndex(Unknown Source)
at com.microsoft.jdbc.base.BaseResultSet.getLong(Unknown Source)
at com.microsoft.jdbc.base.BaseResultSet.getLong(Unknown Source)
at de.objectcode.jdbcfix.ResultSetFix.getLong(ResultSetFix.java:444)
at net.sf.hibernate.type.LongType.get(LongType.java:18)
at net.sf.hibernate.type.NullableType.nullSafeGet(NullableType.java:62)
at net.sf.hibernate.type.NullableType.nullSafeGet(NullableType.java:53)
at net.sf.hibernate.collection.AbstractCollectionPersister.readKey(AbstractCollectionPersister.java:379)
at net.sf.hibernate.loader.Loader.readCollectionElement(Loader.java:282)
at net.sf.hibernate.loader.Loader.doQuery(Loader.java:214)
at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:128)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:905)
at net.sf.hibernate.loader.Loader.loadCollection(Loader.java:880)
at net.sf.hibernate.loader.OneToManyLoader.initialize(OneToManyLoader.java:80)
at net.sf.hibernate.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:284)
at net.sf.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:3131)
at net.sf.hibernate.collection.PersistentCollection.forceInitialization(PersistentCollection.java:331)
at net.sf.hibernate.impl.SessionImpl.initializeNonLazyCollections(SessionImpl.java:3005)
at net.sf.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:133)
at net.sf.hibernate.loader.Loader.list(Loader.java:918)
at net.sf.hibernate.hql.QueryTranslator.list(QueryTranslator.java:983)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1473)
at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:45)
at de.objectcode.canyon.persistent.instance.InstanceRepository.findProcessInstances(InstanceRepository.java:306)
at de.objectcode.canyon.jmx.admin.ProcessAdmin.listProcessInstances(ProcessAdmin.java:111)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ ... much much more JBoss related stuff ... ]
Obviously Hibernate accesses the columns in the ResultSet in the wrong order, i.e. first columns 3,4,5,6,7,8,9,10,11 then column 2.
The MS-Driver might be a little bit prissy here, but if I remember die JDBC-Spec right a ResultSet is not obliged to allow column access in arbirary order. So I think this is indeed a bug in Hibernate.
---------------------------------------------------------------------
JIRA INFORMATION:
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.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
93 messages has been excluded from this view by a project administrator.
