hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-424) Exception wrappers should not add a message

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

The following comment has been added to this issue:

     Author: John Kristian
    Created: Mon, 27 Oct 2003 2:19 PM
       Body:
It's OK with me that Hibernate won't change.  I already have code that works around it; it wasn't hard to write and I don't expect it will be hard to maintain.  Let's go work on something else that matters more.  But I can't resist these parting shots:

No, java.lang.Throwable doesn't implement org.apache.commons.lang.exception.Nestable.

It's true that 'instanceof Nestable' is not a reliable factor for deciding whether an exception is a wrapper.  But that's a bug, from my point of view.  Higher-level code needs to remove wrappers.  It would be better if the wrappers helped with this.

One can tell whether the exception occurred in a callback or validator by looking at the wrapper class and/or stack trace.  That's enough for me; I don't feel a need to repeat the same fact in the message.  I prefer a message that's meaningful and interesting to an end user or high level caller.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:40 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


---------------------------------------------------------------------
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-424) Exception wrappers should not add a message

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Mon, 27 Oct 2003 1:41 PM
       Body:
eh - HibernateException is Nestable and in JDK 1.4 ALL throwables is by default nestable...so, being Nestable (or a JDK 1.4. throwable) is not anything you can use to "detect" a wrapper exception.

Similarily, you cannot just use the rule about "if the message is equals to the lower exception" to detect a wrapper....that you should use the actual type - that's the only mechanism we have available.

Because then it would be a very explicit and "trackable" decision ;)

...but we won't change this in Hibernate since NOT adding something to the message is also bad since it makes it impossible to distinguish from the nested exception message - and that is worse in my book ;)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:40 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


---------------------------------------------------------------------
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-426) Enable observation of StaleObjectStateException

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-426
    Summary: Enable observation of StaleObjectStateException
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Mon, 27 Oct 2003 11:46 AM
    Updated: Mon, 27 Oct 2003 11:46 AM

Description:
Please enable application software to take action whenever optimistic concurrency control fails (for example, whenever a database change fails because the version of an affected row is different from the version last read).  As I understand it, whenever Hibernate detects this it throws a StaleObjectStateException, which is helpful.  But StaleObjectStateException might propagate from any one of many Hibernate methods, which makes it difficult for an application to observe it.

I'd like one method in my application to be called whenever Hibernate throws a StaleObjectStateException.  (In my application, that method will evict stale entries from the global cache, using an algorithm that's too expensive to execute more frequently.)

A related forum thread: http://forum.hibernate.org/viewtopic.php?t=925032

The Observer pattern (from 'Design Patterns') seems applicable here.


---------------------------------------------------------------------
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-424) Exception wrappers should not add a message

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

The following comment has been added to this issue:

     Author: John Kristian
    Created: Mon, 27 Oct 2003 11:24 AM
       Body:
I agree it's not an easy call.  And it doesn't matter much which way it works, so it's reasonable to choose the low-effort option.  You all have better things to do, I'm sure.

My example 'unwrap' algorithm wasn't clear, I fear.  A rough translation to English would be: a Nestable is merely a wrapper if it contains a cause and no message except the message of its cause.  This would apply to any HibernateException, since HibernateException implements org.apache.commons.lang.exception.Nestable.

I think it's a Good Thing for classes in an inheritance hierarchy to behave consistently.  In this case, it would be good for all classes that extend HibernateException to use the same convention for indicating that they are merely a wrapper.  It would be better for all classes that implement Nestable to do likewise.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:40 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


---------------------------------------------------------------------
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-122) Global "on/off" property for SessionFactory-level cache

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

The following comment has been added to this issue:

     Author: Jesse Costello-Good
    Created: Mon, 27 Oct 2003 8:17 AM
       Body:
I think this issue is still valid even with the 2.1 DTDs
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-122
    Summary: Global "on/off" property for SessionFactory-level cache
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0rc2

   Assignee: 
   Reporter: Markus Menner

    Created: Fri, 6 Jun 2003 1:41 AM
    Updated: Fri, 6 Jun 2003 1:41 AM

Description:
It would be nice to have a property to switch on/off SessionFactory-level cache (for example to check performance improvements caching vs. no-caching).

At the moment you have to remove/add the jcs-cache tags in the mapping files.





---------------------------------------------------------------------
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-425) Many-to-one With Join Table

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-425
    Summary: Many-to-one With Join Table
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Jesse Costello-Good

    Created: Mon, 27 Oct 2003 7:06 AM
    Updated: Mon, 27 Oct 2003 7:06 AM

Description:
http://forum.hibernate.org/viewtopic.php?p=2175822#2175822

I propose allowing a many-to-one/one-to-many relationship between two classes be implemented with a separate join table.

The join table would look like: 

many_id int not null, 
one_id int not null unique, 
primary key (many_id, one_id) 

This would be useful if for some reason you didn't want to change the many side table to include a FK to the one side (i.e. there are very many rows but very few relationships, so for space efficiency), you are migrating from a many-to-many relationship, or you plan to migrate eventually to a many-to-many relationship. 

many-to-many is unsatisfactory for this situation because on the many side class I want only a simple pointer to the single related object; I don't want to deal with a collection.


---------------------------------------------------------------------
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-228) Support deleting collections

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Mon, 27 Oct 2003 6:14 AM

we may at some stage support "batch deletes", but there is no reason to change any APIs for this.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-228
    Summary: Support deleting collections
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Mathias Bogaert

    Created: Mon, 4 Aug 2003 7:02 AM
    Updated: Mon, 27 Oct 2003 6:14 AM
Environment: Hibernate 2.0.2

Description:
It would be really cool if one could do this:

session.delete(pm.getSession().createCriteria(Dg.class).list());


---------------------------------------------------------------------
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-399) Query.setLockMode support for databases that do not support FOR UPDATE OF

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Mon, 27 Oct 2003 5:47 AM

Fixed.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-399
    Summary: Query.setLockMode support for databases that do not support FOR UPDATE OF
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5
   Versions:
             2.0.3

   Assignee: Gavin King
   Reporter: Gerjon de Vries

    Created: Tue, 14 Oct 2003 8:02 AM
    Updated: Mon, 27 Oct 2003 5:47 AM
Environment: MySql 3.23.48-Max, using mysql-connector-java-3.0.8-stable

Description:
Query.setLockMode("alias", LockMode.UPGRADE) won't set a lockmode if the dialect does not support "FOR UPDATE OF" syntax. However, if the query is on only one table, or if all table aliases have a lockmode.upgrade, it could still set the lockmode by using "FOR UPDATE" instead of FOR UPDATE OF.

Also, instead of silently ignoring the lockmode if the dialect does not support FOR UPDATE OF, one could make a case case for using "FOR UPDATE"  instead, for such dialects. This would assure the at least the specified locks are set, while the current behaviour is to just ignore the locks.



---------------------------------------------------------------------
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-302) hbm2java: use-in-tostring for discriminator

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sun, 26 Oct 2003 11:11 PM

This makes no sense; the discriminator is not a property of the class.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-302
    Summary: hbm2java: use-in-tostring for discriminator
       Type: New Feature

     Status: Closed
   Priority: Trivial
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             toolset

   Assignee: 
   Reporter: John Meredith

    Created: Mon, 1 Sep 2003 3:26 AM
    Updated: Sun, 26 Oct 2003 11:11 PM

Description:
Only a conveniece ie:

<discriminator column="subclass" type="string">
  <meta attribute="use-in-tostring">true</meta>
</discriminator>

  - John


---------------------------------------------------------------------
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-132) Query by Criteria enhancement

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

Message:

   The following issue has been re-assigned.

   Assignee: Gavin King (mailto:ga...@in...)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-132
    Summary: Query by Criteria enhancement
       Type: Improvement

     Status: Assigned
   Priority: Minor

    Project: Hibernate2
   Versions:
             2.1

   Assignee: Gavin King
   Reporter: Grzegorz Mucha

    Created: Thu, 12 Jun 2003 3:59 AM
    Updated: Thu, 23 Oct 2003 1:33 PM

Description:
Is there a plan to add some extensions to Criteria API? Since there is now FETCH support in Criteria, a nice thing would be to allow users sorting the criteria returned not only by class properties, but the associated classes' properties as well.

example:

class Task {
  User user;
........

}

Criteria crit=session.createCriteria(Task.class);
crit.addOrder(Order.asc("user.lastName");

I know it can be done in java,by applying own sorters for the returned list, though I'd prefer a single step process


---------------------------------------------------------------------
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-417) support createCriteria() for <key-many-to-one>

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

The following comment has been added to this issue:

     Author: Sebastien Cesbron
    Created: Fri, 24 Oct 2003 8:21 AM
       Body:
Gavin

What do you mean by "won't be very soon" ?
All our application is based on the criteria API and we have a lot of key-many-to-one. So I just want to know if I can wait for the correction of if I have to find a workaround (maybe dynamic HQL creation) ?
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-417
    Summary: support createCriteria() for <key-many-to-one>
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: Sebastien Cesbron

    Created: Wed, 22 Oct 2003 3:07 AM
    Updated: Thu, 23 Oct 2003 1:27 PM
Environment: Win2k
SQLServer with jTds driver

Description:
I have one class Bar with a primary key composed of a 'key-many-to-one' to a class Foo.
I want to find a Bar instance with a Foo id so I have this criteria :

Criteria criteria = session.createCriteria(Bar.class);

criteria.createCriteria("foo").add(Expression.eq("id", new Integer(1)));

Bar bar = (Bar) criteria.uniqueResult();

Then I have this sql statement

select this.ID_FOO as ID_FOO0_, this.text as text0_ from BAR this where x0_.id=1


which fails because x0_ isn't defined.

With an HQL query it works.


---------------------------------------------------------------------
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-395) Lazy Initialization used even when collection mapping says lazy="false"

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 25 Oct 2003 5:06 PM

Thanks! Fixed.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-395
    Summary: Lazy Initialization used even when collection mapping says lazy="false"
       Type: Bug

     Status: Closed
   Priority: Blocker
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5
   Versions:
             2.1 beta 3
             2.1 beta 4

   Assignee: 
   Reporter: Jason Carreira

    Created: Mon, 13 Oct 2003 4:46 PM
    Updated: Sat, 25 Oct 2003 5:06 PM
Environment: We use Oracle with WebLogic and WebSphere, but I've included a test case which fails as unit tests running against HSQL

Description:
If a child class has a Proxy (all the ones I've tested have themselves as the proxy class) and the parent class has a <set> mapping to the child class with lazy="false", then, if session.load(Parent.class, parentId) is called, then child collection will be lazily initialized. This doesn't happen with session.find(), for some reason. 


---------------------------------------------------------------------
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-380) Use ResultSet.getGeneratedKeys() when supported by JDBC driver

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

The following issue has been updated:

    Updater: David Morris (mailto:dmm...@ce...)
       Date: Sat, 25 Oct 2003 3:38 PM
    Comment:
Here is the updated patch. I had some problems with the Settings and SettingsFactory patch. They come up with every line changed any way that I try to build the patch, however in a comparision view with Eclipse they come up correctly. I have run into this when sharing CVS client directories between Windows/Linux CVS clients. I don't see how that could be the problem here.
    Changes:
             Attachment changed to getgeneratedkeys.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-380
    Summary: Use ResultSet.getGeneratedKeys() when supported by JDBC driver
       Type: Improvement

     Status: Assigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: Gavin King
   Reporter: David Morris

    Created: Sat, 4 Oct 2003 1:02 AM
    Updated: Sat, 25 Oct 2003 3:38 PM
Environment: JDBC 3.0 Drivers with 1.4 JDKs. MySql and DB2 both have JDBC drivers that support get generated keys.

Description:
Retrieve ResultSet of natively generated keys after inserting records into databases that provide this support. Performance is genrally better with this technique. The code change should be backward compatable with 1.3 JREs and older JDBC drivers.


---------------------------------------------------------------------
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-380) Use ResultSet.getGeneratedKeys() when supported by JDBC driver

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

The following comment has been added to this issue:

     Author: David Morris
    Created: Sat, 25 Oct 2003 3:40 PM
       Body:
I uploaded the new patch. For some reason Eclipse and Ant both built the Settings and SettingsFactory patch as completely changed but in a comparision view they look right.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-380
    Summary: Use ResultSet.getGeneratedKeys() when supported by JDBC driver
       Type: Improvement

     Status: Assigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: Gavin King
   Reporter: David Morris

    Created: Sat, 4 Oct 2003 1:02 AM
    Updated: Sat, 25 Oct 2003 3:38 PM
Environment: JDBC 3.0 Drivers with 1.4 JDKs. MySql and DB2 both have JDBC drivers that support get generated keys.

Description:
Retrieve ResultSet of natively generated keys after inserting records into databases that provide this support. Performance is genrally better with this technique. The code change should be backward compatable with 1.3 JREs and older JDBC drivers.


---------------------------------------------------------------------
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-424) Exception wrappers should not add a message

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

The following issue has been updated:

    Updater: John Kristian (mailto:jkr...@do...)
       Date: Thu, 23 Oct 2003 7:40 PM
    Changes:
             Attachment changed to nomsg.diff-u
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:40 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


---------------------------------------------------------------------
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-395) Lazy Initialization used even when collection mapping says lazy="false"

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

The following issue has been updated:

    Updater: Jason Carreira (mailto:jas...@no...)
       Date: Thu, 23 Oct 2003 12:04 PM
    Comment:
Here's a new version that's not proxied and that fails because the collection is not loaded when the parent is gotten using session.load(). I've added in caching using the HashtableCacheProvider, as I think it's the loading when things are cached that is the problem.
    Changes:
             Attachment changed to src.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-395
    Summary: Lazy Initialization used even when collection mapping says lazy="false"
       Type: Bug

     Status: Unassigned
   Priority: Blocker

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 3
             2.1 beta 4

   Assignee: 
   Reporter: Jason Carreira

    Created: Mon, 13 Oct 2003 4:46 PM
    Updated: Thu, 23 Oct 2003 12:04 PM
Environment: We use Oracle with WebLogic and WebSphere, but I've included a test case which fails as unit tests running against HSQL

Description:
If a child class has a Proxy (all the ones I've tested have themselves as the proxy class) and the parent class has a <set> mapping to the child class with lazy="false", then, if session.load(Parent.class, parentId) is called, then child collection will be lazily initialized. This doesn't happen with session.find(), for some reason. 


---------------------------------------------------------------------
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-414) Informix dialect creates syntax errors in IDS 9.4

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Fri, 24 Oct 2003 11:03 AM
       Body:
Please provide a patch for this.

Typing/copying code from a comment is so much harder and errorprone compared to a good old patch ;)


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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-414
    Summary: Informix dialect creates syntax errors in IDS 9.4
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.0.2

   Assignee: 
   Reporter: Finn McCann

    Created: Tue, 21 Oct 2003 11:01 AM
    Updated: Tue, 21 Oct 2003 11:01 AM
Environment: Hibernate2 on JDK1.4 on Win2000, talking via Informix JDBC 2.21.JC5 driver to Informix IDS 9.4 on another Windows 2000 box.

Description:
Having tested Informix dialect in Hibernate2 against Informix IDS v9.4, we found a couple of issues: 

1.  Serial ids:

<id name="id" column="ID" length="32" unsaved-value="null">
   <generator class="uuid.hex"/>
</id>

creates a data type:

INT8 SERIAL   

instead of:

SERIAL8

The "INT8 SERIAL" causes a syntax error in IDS 9.4.

2. Foreign Key constraint names:

<set name="upliftRates" lazy="true" cascade="all" order-by="EFFECTIVE_DATE desc">
        <key column="NETWORK_ID" length="32"/>
        <one-to-many class="com.capetechnologies.multinet.domain.UpliftRate"/>
</set>

creates this ALTER TABLE statement:

alter table MULTINET_TAX_RATES add constraint FKE1700D046924EC foreign key (NETWORK_ID) references MULTINET_NETWORK

instead of:

alter table MULTINET_TAX_RATES add constraint foreign key (NETWORK_ID) references MULTINET_NETWORK constraint FKE1700D046924EC

Having "CONSTRAINT <constraint name>" within the statement instead of at the end causes a syntax error.

This also applies to adding UNIQUE CONSTRAINTs.



---------------------------------------------------------------------
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-326) Persister assigned to a class not used when persisting a Set

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

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Sat, 25 Oct 2003 8:22 AM

HB-419
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-326
    Summary: Persister assigned to a class not used when persisting a Set
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5
   Versions:
             2.0 final

   Assignee: 
   Reporter: Nick Johnson

    Created: Thu, 11 Sep 2003 4:56 PM
    Updated: Sat, 25 Oct 2003 8:22 AM
Environment: JDK 1.4 on Win2k

Description:
When persisting a Set, the persister for the class defined within the Set is not used.  For example, with a mapping like this:

<class name="foo" persister="FooPersister">
   <!-- ... -->
   <set name="relatedStuff">
       <key column="related_stuff_key" />
       <one-to-many class="bar" />
   </set>
</class>

<class name="bar" persister="BarPersister">
<!-- ... -->
</class>

Operations on the set "relatedStuff" will result in SQL being generated rather than the necessary operations being handed off to BarPersister.

Another alternative or possible solution to this problem would be the ability to define a custom persister for Hibernate's collections classes; eg, "<set name="relatedStuff" persister="CustomSetPersister">"

This problem arose because we need to control how a many-to-many-style table is persisted (we use stored procedures to do inserts, updates and deletes).  Because of the way the tables are normalized and because of the requirements of the system (arbitrary linkage between collections and the necessity of interoperating with existing infrastructure) the schema looks something like this:

Group
-----
group_id    number primary key
(other attributes on group follow)

Group_member
------------
parent_group_id    number (references the group_id in Group)
child_group_id     number (ditto)

The original problem is that we've been unsuccessful in getting customized persistence for the Group_member table.  Even creating a custom persister for the Group_member table still results in SQL getting generated rather than the custom persister being used.

This turns out to be a difficult thing to describe, so if what I've said isn't terribly clear, I'm more than happy to try to clarify ambiguities.


---------------------------------------------------------------------
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] Resolved: (HB-419) Patches to make Hibernate use a custom persister

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

Message:

   The following issue has been resolved as FIXED.

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-419
    Summary: Patches to make Hibernate use a custom persister
       Type: Patch

     Status: Resolved
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5

   Assignee: Max Rydahl Andersen
   Reporter: Nick Johnson

    Created: Wed, 22 Oct 2003 10:18 AM
    Updated: Sat, 25 Oct 2003 8:20 AM
Environment: JDK 1.4 on win32

Description:
See HB-326 for a problem 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

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-419) Patches to make Hibernate use a custom persister

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Sat, 25 Oct 2003 8:20 AM
       Body:
Found the missing pieces and it is now committed.

The only thing we are missing now is a small good testcase ;)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-419
    Summary: Patches to make Hibernate use a custom persister
       Type: Patch

     Status: In Progress
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5

   Assignee: Max Rydahl Andersen
   Reporter: Nick Johnson

    Created: Wed, 22 Oct 2003 10:18 AM
    Updated: Sat, 25 Oct 2003 7:45 AM
Environment: JDK 1.4 on win32

Description:
See HB-326 for a problem 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

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-384) Add support for custom collection persisters

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

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Sat, 25 Oct 2003 8:21 AM

HB-419
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-384
    Summary: Add support for custom collection persisters
       Type: New Feature

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 5
   Versions:
             2.1

   Assignee: Max Rydahl Andersen
   Reporter: Max Rydahl Andersen

    Created: Tue, 7 Oct 2003 2:14 PM
    Updated: Sat, 25 Oct 2003 8:21 AM

Description:
Add support for Custom collection persisters (for eg. allowing usage of Stored Procedures to persister collections)


---------------------------------------------------------------------
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-419) Patches to make Hibernate use a custom persister

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Sat, 25 Oct 2003 7:46 AM
       Body:
seem to be missing some stuff and the patch is not directly patchable ;(

...but i'll try to collect the missing pieces from my original patch
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-419
    Summary: Patches to make Hibernate use a custom persister
       Type: Patch

     Status: In Progress
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: Max Rydahl Andersen
   Reporter: Nick Johnson

    Created: Wed, 22 Oct 2003 10:18 AM
    Updated: Sat, 25 Oct 2003 7:45 AM
Environment: JDK 1.4 on win32

Description:
See HB-326 for a problem 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

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-132) Order support for joined Criteria

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

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Thu, 23 Oct 2003 1:34 PM
    Changes:
             summary changed from Query by Criteria enhancement
             priority changed from Minor
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-132
    Summary: Order support for joined Criteria
       Type: Improvement

     Status: Assigned
   Priority: Major

    Project: Hibernate2
   Versions:
             2.1

   Assignee: Gavin King
   Reporter: Grzegorz Mucha

    Created: Thu, 12 Jun 2003 3:59 AM
    Updated: Thu, 23 Oct 2003 1:34 PM

Description:
Is there a plan to add some extensions to Criteria API? Since there is now FETCH support in Criteria, a nice thing would be to allow users sorting the criteria returned not only by class properties, but the associated classes' properties as well.

example:

class Task {
  User user;
........

}

Criteria crit=session.createCriteria(Task.class);
crit.addOrder(Order.asc("user.lastName");

I know it can be done in java,by applying own sorters for the returned list, though I'd prefer a single step process


---------------------------------------------------------------------
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-424) Exception wrappers should not add a message

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Sat, 25 Oct 2003 6:22 AM
       Body:
well - it's not an easy call ;)

I'm inclined to say that if you want to do automatically "unwrapping" then it is much safer and sound to only do it on specific exceptions instead of relying on some .equals() relation between two exceptions!

So, we'll keep it as it is (unless you got a better argument ;)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:40 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


---------------------------------------------------------------------
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-424) Exception wrappers should not add a message

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-424
    Summary: Exception wrappers should not add a message
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 4

   Assignee: 
   Reporter: John Kristian

    Created: Thu, 23 Oct 2003 7:39 PM
    Updated: Thu, 23 Oct 2003 7:39 PM

Description:
The attached patch would be an improvement, from my point of view.

Exception classes that merely wrap another exception should not add anything to the message.  One reason is to simplify the implementation of code like this, which aims to remove such wrappers:

if (t instanceof Nestable || t instanceof InvocationTargetException || t instanceof UndeclaredThrowableException) {
    cause = t.getCause();
    if (cause != null) {
        String message = t.getMessage();
        if (message != null && message.length() > 0
            && ! message.equals(cause.getMessage()))
        {
            return t;
        }
    }
} else if (t instanceof etc...

Such code need not require special cases for Hibernate exceptions, if they refrain from adding to the message (as in the attached patch).


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