hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-600) hbm2java can't mapping joined-subclasses correctly which are in independent files from the file of the super class.

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Eileen Huan
    Created: Mon, 5 Jan 2004 6:19 AM
       Body:
A .zip file has been uploaded by me as Attachment of this bug report.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-600


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-600
    Summary: hbm2java can't mapping joined-subclasses correctly which are in independent files from the file of the super class.
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1

   Assignee: 
   Reporter: Eileen Huan

    Created: Mon, 5 Jan 2004 6:16 AM
    Updated: Mon, 5 Jan 2004 6:19 AM
Environment: Apache Ant version 1.5.4 compiled on August 12 2003
Buildfile: build.xml
Detected Java version: 1.4 in: C:\j2sdk1.4.2_03\jre
Detected OS: Windows 2000

Description:
I have posted my problem on hibernate forum as "http://forum.hibernate.org/viewtopic.php?t=926802&sid=a04167043b0b8cd84c79b9d16b332a7e".



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-600) hbm2java can't mapping joined-subclasses correctly which are in independent files from the file of the super class.

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-600


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-600
    Summary: hbm2java can't mapping joined-subclasses correctly which are in independent files from the file of the super class.
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.1

   Assignee: 
   Reporter: Eileen Huan

    Created: Mon, 5 Jan 2004 6:16 AM
    Updated: Mon, 5 Jan 2004 6:16 AM
Environment: Apache Ant version 1.5.4 compiled on August 12 2003
Buildfile: build.xml
Detected Java version: 1.4 in: C:\j2sdk1.4.2_03\jre
Detected OS: Windows 2000

Description:
I have posted my problem on hibernate forum as "http://forum.hibernate.org/viewtopic.php?t=926802&sid=a04167043b0b8cd84c79b9d16b332a7e".



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-599) delete all entities of persistent class

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-599


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-599
    Summary: delete all entities of persistent class
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Alexey Kaigorodov

    Created: Mon, 5 Jan 2004 5:29 AM
    Updated: Mon, 5 Jan 2004 5:29 AM

Description:
I propose add method 

Session.deleteAll(Class persistentClass)

which delete all rows from entity's table, evict all entities of persistentClass from session cache and second level cache.

--
With best regards,
Alex 


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-598) ehcache is deemed optional, but it is actually required

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-598


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-598
    Summary: ehcache is deemed optional, but it is actually required
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Attila Szegedi

    Created: Sun, 4 Jan 2004 10:29 AM
    Updated: Sun, 4 Jan 2004 10:29 AM

Description:
ehcache.jar is specified as "optional" in lib/README.txt. However if Hibernate is initialized without specifying explicit value for "hibernate.cache.provider_class", it will default to "net.sf.ehcache.hibernate.Provider", and a ClassNotFoundException will be thrown if ehcache.jar is not present. Either improve the documentation to say something like:
 "required by default, except if you specify another cache provider"
or alternatively work around to remove this implicit reqiured dependency.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-597) Criteria API - NOT IN not working on MySQL

[<leg...@at...>]

Message:

   The following issue has been re-assigned.

   Assignee: Gavin King (mailto:ga...@hi...)
   Assigner: Max Rydahl Andersen (mailto:xa...@xa...)
       Date: Fri, 2 Jan 2004 6:29 PM
    Comment:
throwing this at gavin as he is the weird sql man ;)
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Open
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: Gavin King
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Fri, 2 Jan 2004 6:29 PM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches to fix this.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-597) Criteria API - NOT IN not working on MySQL

[<leg...@at...>]

The following issue has been updated:

    Updater: Michael Gloegl (mailto:gl...@ok...)
       Date: Fri, 2 Jan 2004 5:44 PM
    Comment:
Possiblity 3 - Ugly instanceof test in NotExpression to place the NOT just before the in if the negated Criterion is a InExpression
    Changes:
             Attachment changed to notExpression_InstanceOf.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Fri, 2 Jan 2004 5:44 PM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches to fix this.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-597) Criteria API - NOT IN not working on MySQL

[<leg...@at...>]

The following issue has been updated:

    Updater: Michael Gloegl (mailto:gl...@ok...)
       Date: Fri, 2 Jan 2004 5:44 PM
    Comment:
Possiblity 2 - a new NotInExpression which generates a sql fragment like "columname NOT IN ( ? , ? )"
    Changes:
             Attachment changed to newNotInExpression.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Fri, 2 Jan 2004 5:44 PM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches to fix this.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-597) Criteria API - NOT IN not working on MySQL

[<leg...@at...>]

The following issue has been updated:

    Updater: Michael Gloegl (mailto:gl...@ok...)
       Date: Fri, 2 Jan 2004 5:43 PM
    Comment:
Explicit generation of brackets in NotExpression
    Changes:
             Attachment changed to notExpression_Brackets.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Fri, 2 Jan 2004 5:43 PM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches to fix this.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-597) Criteria API - NOT IN not working on MySQL

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-597


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-597
    Summary: Criteria API - NOT IN not working on MySQL
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Michael Gloegl

    Created: Fri, 2 Jan 2004 5:42 PM
    Updated: Fri, 2 Jan 2004 5:42 PM
Environment: Hibernate 2.1.1, MySQL

Description:
On MySQL the SQL generated by a Criteria query like

Object o =
	session
		.createCriteria(Event.class)
		.add(Expression.not(Expression.in("id", id_values)))
		.uniqueResult();

does not work. Hibernate generates a SQL like 

SELECT * FROM Event WHERE NOT id IN ( 1, 2, 3, 4, 5  ) 

This should work, but MySQL does not get the operator precedences right. This works by using explicit brackets, or by placing the NOT after the column name.

I attatch some possible patches to fix this.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-596) AbstractQueryImpl.setParameterList may have 0 length list

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-596


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-596
    Summary: AbstractQueryImpl.setParameterList may have 0 length list
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Chris Mercer

    Created: Fri, 2 Jan 2004 12:57 PM
    Updated: Fri, 2 Jan 2004 12:57 PM
Environment: Hibernate 2.1.1, mysql

Description:
Here is the source code for the method

public Query setParameterList(String name, Collection vals) throws HibernateException {
		setParameterList(name, vals, guessType( vals.iterator().next() ) );
		return this;
	}

The problems comes in when the vals collection is size 0.  The vals.iterator().next() will fail with a NoSuchElementException. 
 



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-595) DB2 dialect extension for DB2 UDB for iSeries aka DB2/400

[<leg...@at...>]

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Fri, 2 Jan 2004 11:06 AM

In cvs - thanx
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-595


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-595
    Summary: DB2 dialect extension for DB2 UDB for iSeries aka DB2/400
       Type: Patch

     Status: Closed
   Priority: Trivial
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1.1
   Versions:
             2.1

   Assignee: 
   Reporter: Peter DeGregorio

    Created: Fri, 2 Jan 2004 10:32 AM
    Updated: Fri, 2 Jan 2004 11:06 AM
Environment: Hibernate Version 2.1 with DB2 Universal Database for iSeries (AS/400) V5R2 

Description:
DB2/400 SQL differs from DB2 UDB for Linux/Unix/Windows in several respects which affect its use with Hibernate. A subclass of DB2Dialect is provided here to address the problems that arose when running the sample application "eg" against DB2/400. Also, additional lines for hibernate.properties are given to make use of the new class. Among the differences between DB2 UDB and DB2/400 are identity columns, rownumber() over() and whether limit may be specified as a variable. 

Index: src/hibernate.properties
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/src/hibernate.properties,v
retrieving revision 1.19
diff -u -r1.19 hibernate.properties
--- src/hibernate.properties	15 Jun 2003 08:15:22 -0000	1.19
+++ src/hibernate.properties	2 Jan 2004 16:01:25 -0000
@@ -41,6 +41,18 @@
 #hibernate.connection.username db2
 #hibernate.connection.password db2
 
+## DB2/400 
+
+#hibernate.dialect net.sf.hibernate.dialect.DB2400Dialect 
+## Native driver
+##hibernate.connection.driver_class COM.ibm.db2.jdbc.app.DB2Driver 
+##hibernate.connection.url jdbc:db2://systemname
+## or Toolbox driver
+##hibernate.connection.driver_class com.ibm.as400.access.AS400JDBCDriver 
+##hibernate.connection.url jdbc:as400://systemname
+#hibernate.connection.username user
+#hibernate.connection.password password 
+
 
 ## MySQL
 
Index: src/net/sf/hibernate/dialect/DB2400Dialect.java
===================================================================
RCS file: src/net/sf/hibernate/dialect/DB2400Dialect.java
diff -N src/net/sf/hibernate/dialect/DB2400Dialect.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/net/sf/hibernate/dialect/DB2400Dialect.java	2 Jan 2004 16:01:26 -0000
@@ -0,0 +1,48 @@
+package net.sf.hibernate.dialect;
+
+/** 
+* An SQL dialect for DB2/400 
+* @author Peter DeGregorio (pdegregorio) 
+* This class provides support for DB2 Universal Database for iSeries, 
+* also known as DB2/400. 
+*/
+public class DB2400Dialect extends DB2Dialect {
+
+   public DB2400Dialect() {
+      super();
+   }
+
+   public boolean supportsIdentityColumns() {
+      return false;
+   }
+
+   public boolean supportsSequences() {
+      return false;
+   }
+
+   public boolean supportsLimit() {
+      return true;
+   }
+
+   public boolean supportsLimitOffset() {
+      return false;
+   }
+
+   public String getLimitString(String sql, boolean hasOffset, int limit) {
+      return new StringBuffer(sql.length() + 40)
+         .append(sql)
+         .append(" fetch first ")
+         .append(limit)
+         .append(" rows only ")
+         .toString();
+   }
+
+   public boolean useMaxForLimit() {
+      return true;
+   }
+
+   public boolean supportsVariableLimit() {
+      return false;
+   }
+
+}





---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-595) DB2 dialect extension for DB2 UDB for iSeries aka DB2/400

[<leg...@at...>]

The following issue has been updated:

    Updater: Peter DeGregorio (mailto:pde...@pg...)
       Date: Fri, 2 Jan 2004 10:46 AM
    Comment:
BTW this patch is followup forum topic http://forum.hibernate.org/viewtopic.php?t=926695
    Changes:
             Attachment changed to HB-595.txt
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-595&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-595


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-595
    Summary: DB2 dialect extension for DB2 UDB for iSeries aka DB2/400
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Peter DeGregorio

    Created: Fri, 2 Jan 2004 10:32 AM
    Updated: Fri, 2 Jan 2004 10:46 AM
Environment: Hibernate Version 2.1 with DB2 Universal Database for iSeries (AS/400) V5R2 

Description:
DB2/400 SQL differs from DB2 UDB for Linux/Unix/Windows in several respects which affect its use with Hibernate. A subclass of DB2Dialect is provided here to address the problems that arose when running the sample application "eg" against DB2/400. Also, additional lines for hibernate.properties are given to make use of the new class. Among the differences between DB2 UDB and DB2/400 are identity columns, rownumber() over() and whether limit may be specified as a variable. 

Index: src/hibernate.properties
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/src/hibernate.properties,v
retrieving revision 1.19
diff -u -r1.19 hibernate.properties
--- src/hibernate.properties	15 Jun 2003 08:15:22 -0000	1.19
+++ src/hibernate.properties	2 Jan 2004 16:01:25 -0000
@@ -41,6 +41,18 @@
 #hibernate.connection.username db2
 #hibernate.connection.password db2
 
+## DB2/400 
+
+#hibernate.dialect net.sf.hibernate.dialect.DB2400Dialect 
+## Native driver
+##hibernate.connection.driver_class COM.ibm.db2.jdbc.app.DB2Driver 
+##hibernate.connection.url jdbc:db2://systemname
+## or Toolbox driver
+##hibernate.connection.driver_class com.ibm.as400.access.AS400JDBCDriver 
+##hibernate.connection.url jdbc:as400://systemname
+#hibernate.connection.username user
+#hibernate.connection.password password 
+
 
 ## MySQL
 
Index: src/net/sf/hibernate/dialect/DB2400Dialect.java
===================================================================
RCS file: src/net/sf/hibernate/dialect/DB2400Dialect.java
diff -N src/net/sf/hibernate/dialect/DB2400Dialect.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/net/sf/hibernate/dialect/DB2400Dialect.java	2 Jan 2004 16:01:26 -0000
@@ -0,0 +1,48 @@
+package net.sf.hibernate.dialect;
+
+/** 
+* An SQL dialect for DB2/400 
+* @author Peter DeGregorio (pdegregorio) 
+* This class provides support for DB2 Universal Database for iSeries, 
+* also known as DB2/400. 
+*/
+public class DB2400Dialect extends DB2Dialect {
+
+   public DB2400Dialect() {
+      super();
+   }
+
+   public boolean supportsIdentityColumns() {
+      return false;
+   }
+
+   public boolean supportsSequences() {
+      return false;
+   }
+
+   public boolean supportsLimit() {
+      return true;
+   }
+
+   public boolean supportsLimitOffset() {
+      return false;
+   }
+
+   public String getLimitString(String sql, boolean hasOffset, int limit) {
+      return new StringBuffer(sql.length() + 40)
+         .append(sql)
+         .append(" fetch first ")
+         .append(limit)
+         .append(" rows only ")
+         .toString();
+   }
+
+   public boolean useMaxForLimit() {
+      return true;
+   }
+
+   public boolean supportsVariableLimit() {
+      return false;
+   }
+
+}





---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-595) DB2 dialect extension for DB2 UDB for iSeries aka DB2/400

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-595


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-595
    Summary: DB2 dialect extension for DB2 UDB for iSeries aka DB2/400
       Type: Patch

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Peter DeGregorio

    Created: Fri, 2 Jan 2004 10:32 AM
    Updated: Fri, 2 Jan 2004 10:32 AM
Environment: Hibernate Version 2.1 with DB2 Universal Database for iSeries (AS/400) V5R2 

Description:
DB2/400 SQL differs from DB2 UDB for Linux/Unix/Windows in several respects which affect its use with Hibernate. A subclass of DB2Dialect is provided here to address the problems that arose when running the sample application "eg" against DB2/400. Also, additional lines for hibernate.properties are given to make use of the new class. Among the differences between DB2 UDB and DB2/400 are identity columns, rownumber() over() and whether limit may be specified as a variable. 

Index: src/hibernate.properties
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/src/hibernate.properties,v
retrieving revision 1.19
diff -u -r1.19 hibernate.properties
--- src/hibernate.properties	15 Jun 2003 08:15:22 -0000	1.19
+++ src/hibernate.properties	2 Jan 2004 16:01:25 -0000
@@ -41,6 +41,18 @@
 #hibernate.connection.username db2
 #hibernate.connection.password db2
 
+## DB2/400 
+
+#hibernate.dialect net.sf.hibernate.dialect.DB2400Dialect 
+## Native driver
+##hibernate.connection.driver_class COM.ibm.db2.jdbc.app.DB2Driver 
+##hibernate.connection.url jdbc:db2://systemname
+## or Toolbox driver
+##hibernate.connection.driver_class com.ibm.as400.access.AS400JDBCDriver 
+##hibernate.connection.url jdbc:as400://systemname
+#hibernate.connection.username user
+#hibernate.connection.password password 
+
 
 ## MySQL
 
Index: src/net/sf/hibernate/dialect/DB2400Dialect.java
===================================================================
RCS file: src/net/sf/hibernate/dialect/DB2400Dialect.java
diff -N src/net/sf/hibernate/dialect/DB2400Dialect.java
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ src/net/sf/hibernate/dialect/DB2400Dialect.java	2 Jan 2004 16:01:26 -0000
@@ -0,0 +1,48 @@
+package net.sf.hibernate.dialect;
+
+/** 
+* An SQL dialect for DB2/400 
+* @author Peter DeGregorio (pdegregorio) 
+* This class provides support for DB2 Universal Database for iSeries, 
+* also known as DB2/400. 
+*/
+public class DB2400Dialect extends DB2Dialect {
+
+   public DB2400Dialect() {
+      super();
+   }
+
+   public boolean supportsIdentityColumns() {
+      return false;
+   }
+
+   public boolean supportsSequences() {
+      return false;
+   }
+
+   public boolean supportsLimit() {
+      return true;
+   }
+
+   public boolean supportsLimitOffset() {
+      return false;
+   }
+
+   public String getLimitString(String sql, boolean hasOffset, int limit) {
+      return new StringBuffer(sql.length() + 40)
+         .append(sql)
+         .append(" fetch first ")
+         .append(limit)
+         .append(" rows only ")
+         .toString();
+   }
+
+   public boolean useMaxForLimit() {
+      return true;
+   }
+
+   public boolean supportsVariableLimit() {
+      return false;
+   }
+
+}





---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-538) Documentation incorrect for xDoclet jbossservice subtask

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Sherman Wood
    Created: Fri, 2 Jan 2004 8:49 AM
       Body:

"This is incorrect and misleading since the new elements will be put outside the targeted mbean which is undesired since most users will want the elements to be part of the hibernate factory mbean."

I updated the documentation with a change to the XDoclet template that puts the elements inside the MBean

"Moreover, there is support for an additional <depends> element, however, I have yet to get this to work correctly."

XDoclet 1.2b4 does not understand the new depends element.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-538


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-538
    Summary: Documentation incorrect for xDoclet jbossservice subtask
       Type: Bug

     Status: Closed
   Priority: Minor
 Resolution: INCOMPLETE

    Project: Hibernate2
   Versions:
             2.1

   Assignee: 
   Reporter: Roland Chan

    Created: Wed, 10 Dec 2003 9:01 AM
    Updated: Fri, 2 Jan 2004 8:49 AM
Environment: Hibernate 2.1, w/ xDoclet 1.2b4 and CVS Head, and Maven RC1

Description:
The document, http://www.hibernate.org/66.html, describes that with the release of 2.1 final there will be a need to add additional mbean properties to the jboss-service.xml that are not supported by hibernatedoclet.  The method it uses to describe this is to create a merge file and add your elements there.

This is incorrect and misleading since the new elements will be put outside the targeted mbean which is undesired since most users will want the elements to be part of the hibernate factory mbean.

Hopefully fixing this doc will save someone else some time.

Moreover, there is support for an additional <depends> element, however, I have yet to get this to work correctly.


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-594) Typo in treecache.xml - LockingLevel should be IsolationLevel

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-594


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-594
    Summary: Typo in treecache.xml - LockingLevel should be IsolationLevel
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Lari Hotari

    Created: Fri, 2 Jan 2004 2:40 AM
    Updated: Fri, 2 Jan 2004 2:40 AM
Environment: 2.1.1, any

Description:
There is a typo in treecache.xml - LockingLevel should be IsolationLevel.

<attribute name="LockingLevel">REPEATABLE_READ</attribute>

should be:

<attribute name="IsolationLevel">REPEATABLE_READ</attribute>



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-593) Having clause couldn't get the alias in it

[<leg...@at...>]

The following comment has been added to this issue:

     Author: simon xi
    Created: Fri, 2 Jan 2004 2:14 AM
       Body:
For the error message I write in the description, (***message3_.toc as toc2_,******having (message3_.toc=max(message3_.toc))
should be (***message3_.toc******having (message3_.toc=max(message3_.toc))

NOTICE: (***message3_.toc as toc2_******having(toc2_=max(toc2_))) doesn't work

It means if some attribute in the having clause, it should not generate the alias for it. Or it will fail at least against MySQL database
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-593


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-593
    Summary: Having clause couldn't get the alias in it
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: simon xi

    Created: Thu, 1 Jan 2004 6:43 PM
    Updated: Fri, 2 Jan 2004 2:14 AM
Environment: mysql database

Description:
The hibernate generate the attribute of field, but in Having clause, it use the true field name, so the database will say that there is no this field in database.

warning : SQL Error: 1054, SQLState: S0022
2004-1-2 8:37:20 net.sf.hibernate.util.JDBCExceptionReporter logExceptions
Hibernate: select forum0_.id as id0_, category1_.id as id1_, message3_.id as id2_, forum0_.name as name0_, forum0_.priority as priority0_, category1_.name as name1_, category1_.priority as priority1_, category1_.description as descript4_1_, category1_.moderator as moderator1_, category1_.forum as forum1_, message3_.toc as toc2_, message3_.text as text2_, message3_.poster as poster2_, message3_.topic as topic2_, message3_.parent as parent2_, forum0_.id as x0_0_, category1_.id as x1_0_, count(distinct topic2_.id) as x2_0_, count(distinct message3_.id) as x3_0_, message3_.id as x4_0_ from Forum forum0_, Category category1_, Topic topic2_, Message message3_ where (message3_.topic=topic2_.id )and(topic2_.category=category1_.id )and(category1_.forum=forum0_.id ) group by  topic2_.category , category1_.forum having (message3_.toc=max(message3_.toc)) order by  forum0_.priority desc , category1_.priority desc , topic2_.toc desc

fatal: Column not found,  message from server: "Unknown column 'message3_.toc' in 'having clause'"
2004-1-2 8:37:20 net.sf.hibernate.JDBCException <init>

fatal: Could not execute query
java.sql.SQLException: Column not found,  message from server: "Unknown column 'message3_.toc' in 'having clause'"



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-593) Having clause couldn't get the alias in it

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-593


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-593
    Summary: Having clause couldn't get the alias in it
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: simon xi

    Created: Thu, 1 Jan 2004 6:43 PM
    Updated: Thu, 1 Jan 2004 6:43 PM
Environment: mysql database

Description:
The hibernate generate the attribute of field, but in Having clause, it use the true field name, so the database will say that there is no this field in database.

warning : SQL Error: 1054, SQLState: S0022
2004-1-2 8:37:20 net.sf.hibernate.util.JDBCExceptionReporter logExceptions
Hibernate: select forum0_.id as id0_, category1_.id as id1_, message3_.id as id2_, forum0_.name as name0_, forum0_.priority as priority0_, category1_.name as name1_, category1_.priority as priority1_, category1_.description as descript4_1_, category1_.moderator as moderator1_, category1_.forum as forum1_, message3_.toc as toc2_, message3_.text as text2_, message3_.poster as poster2_, message3_.topic as topic2_, message3_.parent as parent2_, forum0_.id as x0_0_, category1_.id as x1_0_, count(distinct topic2_.id) as x2_0_, count(distinct message3_.id) as x3_0_, message3_.id as x4_0_ from Forum forum0_, Category category1_, Topic topic2_, Message message3_ where (message3_.topic=topic2_.id )and(topic2_.category=category1_.id )and(category1_.forum=forum0_.id ) group by  topic2_.category , category1_.forum having (message3_.toc=max(message3_.toc)) order by  forum0_.priority desc , category1_.priority desc , topic2_.toc desc

fatal: Column not found,  message from server: "Unknown column 'message3_.toc' in 'having clause'"
2004-1-2 8:37:20 net.sf.hibernate.JDBCException <init>

fatal: Could not execute query
java.sql.SQLException: Column not found,  message from server: "Unknown column 'message3_.toc' in 'having clause'"



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-592) SessionFactory goes stale after database restart

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Brian Topping
    Created: Thu, 1 Jan 2004 11:02 AM
       Body:
I see.  But if we are not using a connection pool?  If the connection is defined statically in the source? 

It sounds like a work-around is to use connection pools, and a quick fix would be to better document this caveat, that not using connection pools can result in this behavior, and therefore using connection pools in a production environment is essential.  
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-592


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-592
    Summary: SessionFactory goes stale after database restart
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Brian Topping

    Created: Wed, 31 Dec 2003 1:46 PM
    Updated: Thu, 1 Jan 2004 11:02 AM

Description:
It seems impractical to recover a Hibernate SessionFactory from a database restart.  Additionally, Hibernate is kicking back a totally bogus stack trace, one has very little connection to the code that is executed.  (I'll attach that as soon as I can get a copy of one... I restarted the server and didn't save it...)

The problem that I seeing in this particular app is that I am using local configuration objects, not the JBoss service MBean.  I cache the SessionFactory calling Config.buildSessionFactory(), but if the database is restarted, it starts blowing these crazy exceptions.

I'm also looking at this from an architectural perspective.  Confg.buildSessionFactory() is very expensive.  So I can't call it all the time.  I wouldn't mind calling it if I could sense when it needed to be called (i.e. after the database connection is lost), but the exception does not happen until session.find() is called.  Calling SessionFactory.openSession() succeeds just fine.  If the logic required could be wrapped in a SessionFactory facade and the Session that is returned can be validated before it is used by the client, that would not be a problem, and I would welcome a suggestion for a lightweight query or connection validation routine that could be used.  

Should SessionFactory.openSession() be validating the connection before returning it?

Failing a good way to make sure that the Session that is returned is good, I am going to have to write global exception catcher that knows how to determine that the SessionFactory is stale, then kill the cache so that it is reloaded on the next time through.  Color me lazy, but that seems a bit excessive.  

thanks!



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-592) SessionFactory goes stale after database restart

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Gavin King
    Created: Thu, 1 Jan 2004 3:17 AM
       Body:
It is the job of the connection pool to validate connections and toss out broken connections.
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-592


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-592
    Summary: SessionFactory goes stale after database restart
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Brian Topping

    Created: Wed, 31 Dec 2003 1:46 PM
    Updated: Thu, 1 Jan 2004 3:17 AM

Description:
It seems impractical to recover a Hibernate SessionFactory from a database restart.  Additionally, Hibernate is kicking back a totally bogus stack trace, one has very little connection to the code that is executed.  (I'll attach that as soon as I can get a copy of one... I restarted the server and didn't save it...)

The problem that I seeing in this particular app is that I am using local configuration objects, not the JBoss service MBean.  I cache the SessionFactory calling Config.buildSessionFactory(), but if the database is restarted, it starts blowing these crazy exceptions.

I'm also looking at this from an architectural perspective.  Confg.buildSessionFactory() is very expensive.  So I can't call it all the time.  I wouldn't mind calling it if I could sense when it needed to be called (i.e. after the database connection is lost), but the exception does not happen until session.find() is called.  Calling SessionFactory.openSession() succeeds just fine.  If the logic required could be wrapped in a SessionFactory facade and the Session that is returned can be validated before it is used by the client, that would not be a problem, and I would welcome a suggestion for a lightweight query or connection validation routine that could be used.  

Should SessionFactory.openSession() be validating the connection before returning it?

Failing a good way to make sure that the Session that is returned is good, I am going to have to write global exception catcher that knows how to determine that the SessionFactory is stale, then kill the cache so that it is reloaded on the next time through.  Color me lazy, but that seems a bit excessive.  

thanks!



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-587) Lazy collections not lazy when used with second level cache

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Juho Snellman
    Created: Wed, 31 Dec 2003 2:40 PM
       Body:
Perhaps some details on the testcase might explain why such excessively large amount of time is spent assembling the objects back from the cache. It doesn't seem very much like a special case to me.
 
First of all, there's a tree of Nodes (about 500), that have a parent reference and a lazy Set of child-Nodes. Each Node also has a lazy Set of Documents associated with it (and the Documents have a  reference to the parent Node). The Documents (a total of 600 in this test) also have a bit of tree-structured data attached to them (a total of less than 2000 objescts worth of these). This tree is also modeled using parent reference + lazy Sets of children.

The amount of objects isn't very large, so they all fit into the cache comfortably. Once everything is in the cache, loading any object will also result in everything being assembled at once. This is a web application, so for every request we need to do this again. 

I did some more digging in the profiler output (unfortunately the profiler isn't very good at reporting the aggregate time spent inside a function when recursion is involved). As far as I can tell, the problem is that these sorts of "recursively do something to everything" operations magnify even the smallest overheads out of proportion. For example, just calls to the Logger's isTraceEnabled()-method take up 10% of the whole program's execution time! One call might be really cheap, but it ends up being called 30000 times/web request.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-587


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-587
    Summary: Lazy collections not lazy when used with second level cache
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Juho Snellman

    Created: Tue, 30 Dec 2003 8:53 AM
    Updated: Wed, 31 Dec 2003 2:40 PM
Environment: Hibernate 2.1.1
ehcache

Description:
When an object is loaded from the second level cache, any of its collections that are found from the cache are immediately initialized.
This happens for both lazy and non-lazy collections. These initializations then cascade on to the contents of the collection, and their child-collections. 

For a sufficiently large and interconnected graph of objects this results in a disastrous performance loss when caching is enabled. In my particular case a test enabling caching increases the runtime of a test from about 12 minutes to over 40 minutes. In the latter case SessionImpl.getCachedCollection() takes up 68% of the runtime. Disabling caching only for collections brings the runtime back down.
 
Aside from the performance issue, it seems to me that initializing lazy collections is also conceptually wrong. Shouldn't laziness mean "no work is done unless it's neccessary", instead of "nothing is fetched from the DB unless it's neccessary"?

I'm pretty sure this didn't happen with Hibernate 2.0 and JCS. 


---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-592) SessionFactory goes stale after database restart

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-592


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-592
    Summary: SessionFactory goes stale after database restart
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Brian Topping

    Created: Wed, 31 Dec 2003 1:46 PM
    Updated: Wed, 31 Dec 2003 1:46 PM

Description:
It seems impractical to recover a Hibernate SessionFactory from a database restart.  Additionally, Hibernate is kicking back a totally bogus stack trace, one has very little connection to the code that is executed.  (I'll attach that as soon as I can get a copy of one... I restarted the server and didn't save it...)

The problem that I seeing in this particular app is that I am using local configuration objects, not the JBoss service MBean.  I cache the SessionFactory calling Config.buildSessionFactory(), but if the database is restarted, it starts blowing these crazy exceptions.

I'm also looking at this from an architectural perspective.  Confg.buildSessionFactory() is very expensive.  So I can't call it all the time.  I wouldn't mind calling it if I could sense when it needed to be called (i.e. after the database connection is lost), but the exception does not happen until session.find() is called.  Calling SessionFactory.openSession() succeeds just fine.  If the logic required could be wrapped in a SessionFactory facade and the Session that is returned can be validated before it is used by the client, that would not be a problem, and I would welcome a suggestion for a lightweight query or connection validation routine that could be used.  

Should SessionFactory.openSession() be validating the connection before returning it?

Failing a good way to make sure that the Session that is returned is good, I am going to have to write global exception catcher that knows how to determine that the SessionFactory is stale, then kill the cache so that it is reloaded on the next time through.  Color me lazy, but that seems a bit excessive.  

thanks!



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-591) Extra documentation to indicate multi-column indexes are possible

[<leg...@at...>]

The following issue has been updated:

    Updater: Francois Beausoleil (mailto:fb...@us...)
       Date: Wed, 31 Dec 2003 7:54 AM
    Comment:
The diff, in case it was broken in the text.
    Changes:
             Attachment changed to diff.txt
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-591&page=history

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-591


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-591
    Summary: Extra documentation to indicate multi-column indexes are possible
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2

   Assignee: 
   Reporter: Francois Beausoleil

    Created: Wed, 31 Dec 2003 7:53 AM
    Updated: Wed, 31 Dec 2003 7:54 AM
Environment: Tested on Hibernate 2.0.2

Description:
The following patch adds documentation explaining to the user that it is possible to have the SchemaExport tool automatically create indexes.

This patch is a followup to the following thread:
http://forum.hibernate.org/viewtopic.php?t=926694

Index: doc/reference/src/basic_or_mapping.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/basic_or_mapping.xml,v
retrieving revision 1.30
diff -u -r1.30 basic_or_mapping.xml
--- doc/reference/src/basic_or_mapping.xml	1 Aug 2003 16:33:06 -0000	1.30
+++ doc/reference/src/basic_or_mapping.xml	31 Dec 2003 13:50:09 -0000
@@ -1718,6 +1718,27 @@
         unique="true"/>
 </property>]]></programlisting>
 
+
+            <para>
+                Finally, it is also possible to have the <literal>SchemaExport</literal> commandline tool generated
+                required indexes automatically.  For this, use the <literal>index</literal> attribute on
+                <literal>&lt;column&gt;</literal> elements.
+            </para>
+
+                <programlisting><![CDATA[<property 
+    name="lastname">
+    <column 
+        name="LASTNAME" 
+        index="by_last_first"/>
+</property>
+
+<property
+    name="firstname">
+    <column
+        name="FIRSTNAME"
+        index="by_last_first"/>
+</property>]]></programlisting>
+
     </sect1>
 
 



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-591) Extra documentation to indicate multi-column indexes are possible

[<leg...@at...>]

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-591


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-591
    Summary: Extra documentation to indicate multi-column indexes are possible
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2

   Assignee: 
   Reporter: Francois Beausoleil

    Created: Wed, 31 Dec 2003 7:53 AM
    Updated: Wed, 31 Dec 2003 7:53 AM
Environment: Tested on Hibernate 2.0.2

Description:
The following patch adds documentation explaining to the user that it is possible to have the SchemaExport tool automatically create indexes.

This patch is a followup to the following thread:
http://forum.hibernate.org/viewtopic.php?t=926694

Index: doc/reference/src/basic_or_mapping.xml
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/basic_or_mapping.xml,v
retrieving revision 1.30
diff -u -r1.30 basic_or_mapping.xml
--- doc/reference/src/basic_or_mapping.xml	1 Aug 2003 16:33:06 -0000	1.30
+++ doc/reference/src/basic_or_mapping.xml	31 Dec 2003 13:50:09 -0000
@@ -1718,6 +1718,27 @@
         unique="true"/>
 </property>]]></programlisting>
 
+
+            <para>
+                Finally, it is also possible to have the <literal>SchemaExport</literal> commandline tool generated
+                required indexes automatically.  For this, use the <literal>index</literal> attribute on
+                <literal>&lt;column&gt;</literal> elements.
+            </para>
+
+                <programlisting><![CDATA[<property 
+    name="lastname">
+    <column 
+        name="LASTNAME" 
+        index="by_last_first"/>
+</property>
+
+<property
+    name="firstname">
+    <column
+        name="FIRSTNAME"
+        index="by_last_first"/>
+</property>]]></programlisting>
+
     </sect1>
 
 



---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-590) Websphere 4.x and hibernate 2.1 incompatibility

[<leg...@at...>]

Message:

   The following issue has been closed.

---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-590


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-590
    Summary: Websphere 4.x and hibernate 2.1 incompatibility
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
   Versions:
             2.1

   Assignee: 
   Reporter: Niraj

    Created: Tue, 30 Dec 2003 5:01 PM
    Updated: Wed, 31 Dec 2003 4:23 AM
Environment: Websphere 4.x / Db2 version 7.2

Description:
Cannot build the Session Factory in Websphere 4.x with hibernate 2.1

Steps :
1. use the config file as shown below
<?xml version='1.0' encoding='utf-8'?>
 <!DOCTYPE hibernate-configuration PUBLIC "-//Hibernate/Hibernate Configuration DTD 2.0//EN"
 "http://hibernate.sourceforge.net/hibernate-configuration-2.0.dtd">

<hibernate-configuration>

    <session-factory>
        <property name="connection.driver_class">COM.ibm.db2.jdbc.app.DB2Driver</property>
        <property name="connection.url">jdbc:db2:ENTDB</property>
        <property name="connection.username">db2admin</property>
        <property name="connection.password">db2admin</property> 
        <property name="show_sql">true</property>
        <property name="dialect">net.sf.hibernate.dialect.DB2Dialect</property>
        <!--
		<property name="transaction.factory_class">net.sf.hibernate.transaction.JTATransactionFactory</property>
		<property name="transaction.manager_lookup_class">net.sf.hibernate.transaction.WebSphereTransactionManagerLookup</property>
       <property name="jta.UserTransaction">UserTransaction</property>
-->
        <mapping resource="resources/xml/BankInformation.hbm.xml"/>

    </session-factory>

</hibernate-configuration>



2. Call the method
	sessionFactory = new Configuration().configure().buildSessionFactory();


3. We see a Stack trace like this

2003-12-30 15:01:07,973 [main] INFO net.sf.hibernate.connection.DriverManagerConnectionProvider - Hibernate connection pool size: 20
java.lang.ExceptionInInitializerError: java.lang.NullPointerException
	at java.io.Win32FileSystem.normalize(Win32FileSystem.java(Compiled Code))
	at java.io.Win32FileSystem.normalize(Win32FileSystem.java(Compiled Code))
	at java.io.Win32FileSystem.getUserPath(Win32FileSystem.java:283)
	at java.io.Win32FileSystem.resolve(Win32FileSystem.java:299)
	at java.io.File.getCanonicalPath(File.java:454)
	at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1744)
	at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1685)
	at java.lang.Runtime.loadLibrary0(Runtime.java:780)
	at java.lang.System.loadLibrary(System.java:865)
	at COM.ibm.db2.jdbc.app.DB2Driver.<init>(DB2Driver.java:227)
	at COM.ibm.db2.jdbc.app.DB2Driver.<clinit>(DB2Driver.java:130)
	at java.lang.Class.forName1(Native Method)
	at java.lang.Class.forName(Class.java:142)
	at net.sf.hibernate.connection.DriverManagerConnectionProvider.configure(DriverManagerConnectionProvider.java:53)
	at net.sf.hibernate.connection.ConnectionProviderFactory.newConnectionProvider(ConnectionProviderFactory.java:83)
	at net.sf.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:64)
	at net.sf.hibernate.cfg.Configuration.buildSettings(Configuration.java:1091)
	at net.sf.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:737)
	at com.i21.autopay.framework.persist.HibernateManager.init(HibernateManager.java:39)
	at test.workarea.TestHibernate.testHibernate(TestHibernate.java:42)
	at java.lang.reflect.Method.invoke(Native Method)
	at junit.framework.TestCase.runTest(TestCase.java:166)
	at junit.framework.TestCase.runBare(TestCase.java:140)
	at junit.framework.TestResult$1.protect(TestResult.java:106)
	at junit.framework.TestResult.runProtected(TestResult.java:124)
	at junit.framework.TestResult.run(TestResult.java:109)
	at junit.framework.TestCase.run(TestCase.java:131)
	at junit.framework.TestSuite.runTest(TestSuite.java:173)
	at junit.framework.TestSuite.run(TestSuite.java:168)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:329)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:218)
	at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:151)




4. Please note that I recompiled the code with jdk1.3




---------------------------------------------------------------------
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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-587) Lazy collections not lazy when used with second level cache

[<leg...@at...>]

The following comment has been added to this issue:

     Author: Gavin King
    Created: Wed, 31 Dec 2003 4:14 AM
       Body:
Interesting. This functionality was intended and indeed may have changed since 2.0.x. I'm amazed it takes so long to pull stuff from the cache!?
---------------------------------------------------------------------
View the issue:

  http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-587


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-587
    Summary: Lazy collections not lazy when used with second level cache
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1.1

   Assignee: 
   Reporter: Juho Snellman

    Created: Tue, 30 Dec 2003 8:53 AM
    Updated: Wed, 31 Dec 2003 4:14 AM
Environment: Hibernate 2.1.1
ehcache

Description:
When an object is loaded from the second level cache, any of its collections that are found from the cache are immediately initialized.
This happens for both lazy and non-lazy collections. These initializations then cascade on to the contents of the collection, and their child-collections. 

For a sufficiently large and interconnected graph of objects this results in a disastrous performance loss when caching is enabled. In my particular case a test enabling caching increases the runtime of a test from about 12 minutes to over 40 minutes. In the latter case SessionImpl.getCachedCollection() takes up 68% of the runtime. Disabling caching only for collections brings the runtime back down.
 
Aside from the performance issue, it seems to me that initializing lazy collections is also conceptually wrong. Shouldn't laziness mean "no work is done unless it's neccessary", instead of "nothing is fetched from the DB unless it's neccessary"?

I'm pretty sure this didn't happen with Hibernate 2.0 and JCS. 


---------------------------------------------------------------------
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