hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Assigned: (HB-283) Parent class constructor error - prevents compilation of a project

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

Message:

   The following issue has been re-assigned.

   Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-283
    Summary: Parent class constructor error - prevents compilation of a project
       Type: Bug

     Status: Assigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core

   Assignee: Max Rydahl Andersen
   Reporter: Les Hazlewood

    Created: Fri, 22 Aug 2003 9:38 AM
    Updated: Fri, 22 Aug 2003 1:28 PM
Environment: all

Description:
A rewrite of the email I wrote after discovering this bug:

I think I've discovered a fairly serious bug with the joined-subclass class generation.  Max Anderson confirmed this sounds like a bug, so I'm adding it to JIRA.

(Please open attached hbm.xml file for reference when reading the rest of this description):

Given the schema, 

a User ISA Person ISA Party ISA DatabaseObject. 

However, the generated code for the User class calls (in its "minimal" 
constructor): 

super(dbCreationTs, emailAddresses, phoneNumbers, postalAddresses, name); 

There is no constructor in the Person class with that signature (however, there is one like that in the Party class, which is the "Grandparent" of User.  The Person class has only one constructor (no minimal constructor), and its signature is: 

Person (Calendar dbCreationTs, Set emailAddresses, Set phoneNumbers,  Set postalAddresses, String gender, PersonName name); 

Therefore, the User class, in its minimal constructor, is trying to call a super constructor that doesn't exist (its actually trying to call a Grandparent constructor). 

I manually typed in a minimal constructor for Person just like the full constructor above, but leaving out gender, since it is nullable. (I believe this is how you generate a "minimal" constructor - leaving out nullable fields - but I could be wrong).  After doing that, everything compiled fine.

Is there a way that an update could be written fairly soon?  Generated class compilation errors is a pretty substantial bug that would affect anyone.  I also can't continue my current project until the correct OO hierarchy is in place and compiles.  I am certainly willing to help out in any way that I can (testing, coding, etc).

Thanks! 

Les Hazlewood 


---------------------------------------------------------------------
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-281) ".class" with <joined-subclass> problem

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Fri, 22 Aug 2003 1:24 PM
       Body:
Currently, .class may only be applied to <joined-subclass> hierarchies when the enity is being returned in the select clause.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-281
    Summary: ".class" with <joined-subclass> problem
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Simone Ricciardi

    Created: Fri, 22 Aug 2003 2:38 AM
    Updated: Fri, 22 Aug 2003 2:38 AM
Environment: windows 2000

Description:
I've acknowledged an error that happens using "select count (*) ..." 
together to a where clause "... where alias.class = ClassName ". 

Suppose to have two classes: 

public class Foo
{
String id;
String attr1;

public String getId(){ return id; }
public void setId(String id){ this.id = id; }
public String getAttr1(){ return attr1; }
public void setAttr1(String attr1){ this.attr1 = attr1; }
}

public class Bar extends Foo
{
String attr2;

public String getAttr2(){ return attr2; }
public void setAttr2(String attr2){ this.attr2 = attr2; }
}

and the corresponding mapping file: 

<hibernate-mapping>
<class name="test.persistents.Foo" table="Foo">
<id name="id" type="string">
<column name="id" length="32"/>
<generator class="uuid.hex"/>
</id>
<property name="attr1" column="attr1" type="string"/>

<joined-subclass name="test.persistents.Bar" table="Bar">
<key column="foo_id"/>
<property name="attr2" column="attr2" type="string"/>
</joined-subclass>
</class>
</hibernate-mapping>

When I try to make the following query: 

Query query = session.createQuery("select count(*) from Foo foo where foo.class = Foo"); 

I get an error of this type:

java.sql.SQLException: General error, message from server: "Unknown table 'foo0__1' in where clause"
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1651)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:889)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:956)
at com.mysql.jdbc.Connection.execSQL(Connection.java:1874)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1538)
at com.p6spy.engine.logging.P6LogPreparedStatement.executeQuery(P6LogPreparedStatement.java:171)
at net.sf.hibernate.impl.BatcherImpl.getResultSet(BatcherImpl.java:71)
at net.sf.hibernate.loader.Loader.getResultSet(Loader.java:551)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:140)
at net.sf.hibernate.loader.Loader.find(Loader.java:620)
at net.sf.hibernate.hql.QueryTranslator.find(QueryTranslator.java:928)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1343)
at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:76)
at test.Test.main(Test.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)

while if I perform the same query without the select count(*) (select foo from Foo foo where foo.class = Foo) 
all works fine.
Comparing the two queries produced by hibernate in both cases, 
it seems that the error derives from the lack of the "left outer join" with the Bar table in the "from" clause:

with select count(*):
select count(*) as x0_0_ 
from Foo foo0_ 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )

without select count(*):
select foo0_.id as id, 
case when foo0__1.foo_id is not null then 1 
when foo0_.id is not null then 0 end 
as clazz_, 
foo0_.attr1 as attr10_, 
foo0__1.attr2 as attr21_ 
from Foo foo0_ left outer join Bar foo0__1 on foo0_.id=foo0__1.foo_id 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )

in fact the query should be the following:
select count(*) as x0_0_ 
from Foo foo0_ left outer join Bar foo0__1 on foo0_.id=foo0__1.foo_id 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )


---------------------------------------------------------------------
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-282) JCS: Routing *different* classes to *same* JCS Region causes ClassCastException

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Fri, 22 Aug 2003 1:25 PM

This is not a bug; this is how it is designed.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-282
    Summary: JCS: Routing *different* classes to *same* JCS Region causes ClassCastException
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1
             2.0.1
             2.0.2
             2.1 beta 1

   Assignee: 
   Reporter: Bertrand Renuart

    Created: Fri, 22 Aug 2003 5:09 AM
    Updated: Fri, 22 Aug 2003 1:25 PM

Description:
Summary:
--------
Configuring two classes to share the same JCS Region may cause ClassCastException on cache hit.


Description:
------------
By default, Hibernate will use different cache regions for each class, the region name being the class name (class name + property path for collections).
When using the cache config inside hibernate.cfg.xml, it is possible to specify in which region each class should endup. This way, it is possible to direct different classes to the same region.

Internally, Hibernate creates a JCSCache proxy for each class, with a reference to the underlying JCS Region.
If two classes share the same region, then two Hibernate JCSCache proxies are created, both pointing to the same JCS Region.

Object are put and retrieved in/from JCS using a *key*. 
Hibernate uses the persistent ID of the class as key (the Serializable than can be used the load() the object).

Unfortunately, instances of different classes may have the same ID (say a Long if you use the Increment generator). 
If they share the same cache region, one instance will override the other (the cache behaves like a Java Map) - confusing Hibernate on retrieve from cache and causing a ClassCastException (either in your code when casting the return of load(), or inside Hibernate in case of 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] Created: (HB-284) Add <meta attribute="extends"> to <composite-id> for hbm2java

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-284
    Summary: Add <meta attribute="extends"> to <composite-id> for hbm2java
       Type: Improvement

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.2

   Assignee: 
   Reporter: Eric Fenderbosch

    Created: Fri, 22 Aug 2003 1:23 PM
    Updated: Fri, 22 Aug 2003 1:23 PM
Environment: N/A

Description:
  <class
      name="com.fedex.cc.objectlib.tariff.TariffAccessorialState"
      table="TARIFF_ACCESSORIAL">
    <meta attribute="extends">PersistentState</meta>
    <composite-id name="id" class="com.fedex.cc.objectlib.tariff.TariffAccessorialIdentity">
      <key-property name="seqId" column="SEQ_ID" type="long"/>
      <key-property name="tariffId" column="TARIFF_ID" type="long"/>
      <meta attribute="extends">PersistentIdentity</meta>
    </composite-id>
<!-- ... --->
  </class>

This would generate 2 classes:
public class TariffAccessorialState extends PersistentState { ... }
public class TariffAccessorialIdentity extends PersistentIdentity { ... }
Note that TariffAccessorialIdentity extends PersistentIdentity not PersistentState.


---------------------------------------------------------------------
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-280) support formula properties in where clause

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Fri, 22 Aug 2003 1:23 PM
       Body:
Very good idea!

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-280
    Summary: support formula properties in where clause
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Tim Schafer

    Created: Thu, 21 Aug 2003 6:23 PM
    Updated: Thu, 21 Aug 2003 6:23 PM

Description:
Be able to use the property in an HQL where clause
and have the formula inserted into the resulting SQL


---------------------------------------------------------------------
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-282) JCS: Routing *different* classes to *same* JCS Region causes ClassCastException

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

The following issue has been updated:

    Updater: Bertrand Renuart (mailto:ber...@mo...)
       Date: Fri, 22 Aug 2003 5:14 AM
    Comment:
Sample test program that can be used to reproduced the problem.
Contains 2 POJO for persistence, a main TEST class with a main method, the hibernate mapping and configuration files together with the JCS cache.ccf config.

    Changes:
             Attachment changed to hb282-test.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-282
    Summary: JCS: Routing *different* classes to *same* JCS Region causes ClassCastException
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1
             2.0.1
             2.0.2
             2.1 beta 1

   Assignee: 
   Reporter: Bertrand Renuart

    Created: Fri, 22 Aug 2003 5:09 AM
    Updated: Fri, 22 Aug 2003 5:14 AM

Description:
Summary:
--------
Configuring two classes to share the same JCS Region may cause ClassCastException on cache hit.


Description:
------------
By default, Hibernate will use different cache regions for each class, the region name being the class name (class name + property path for collections).
When using the cache config inside hibernate.cfg.xml, it is possible to specify in which region each class should endup. This way, it is possible to direct different classes to the same region.

Internally, Hibernate creates a JCSCache proxy for each class, with a reference to the underlying JCS Region.
If two classes share the same region, then two Hibernate JCSCache proxies are created, both pointing to the same JCS Region.

Object are put and retrieved in/from JCS using a *key*. 
Hibernate uses the persistent ID of the class as key (the Serializable than can be used the load() the object).

Unfortunately, instances of different classes may have the same ID (say a Long if you use the Increment generator). 
If they share the same cache region, one instance will override the other (the cache behaves like a Java Map) - confusing Hibernate on retrieve from cache and causing a ClassCastException (either in your code when casting the return of load(), or inside Hibernate in case of 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-140) Changed Avalon component to work with cocoon 2.0.4

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Fri, 22 Aug 2003 5:23 AM
       Body:
Has this one been fixed ? (we should close it if its so!)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-140
    Summary: Changed Avalon component to work with cocoon 2.0.4
       Type: Patch

     Status: Assigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             toolset

   Assignee: Eric Pugh
   Reporter: Scott Payne

    Created: Wed, 18 Jun 2003 12:47 AM
    Updated: Fri, 20 Jun 2003 11:58 PM

Description:
Simple patch so that the CocoonComponentManager won't throw a ClassCastException when using the HibernateService. It seemed to try to cast it to a Component (fair enough) and this fixed it.

Also a change to the DTD used in the test case, to use the hibernate 2 DTD.


diff -riuwBb -x CVS avalon/src/java/net/sf/hibernate/avalon/HibernateService.java avalon-patched/src/java/net/sf/hibernate/avalon/HibernateService.java
--- avalon/src/java/net/sf/hibernate/avalon/HibernateService.java	2003-06-18 15:37:40.000000000 +1000
+++ avalon-patched/src/java/net/sf/hibernate/avalon/HibernateService.java	2003-06-18 15:21:00.000000000 +1000
@@ -11,7 +11,7 @@
  * @author <a href="mailto:ne...@ap...">Neeme Praks</a>
  * @version $Id: HibernateService.java,v 1.2 2003/06/04 10:44:25 nemecec Exp $
  */
-public interface HibernateService {
+public interface HibernateService extends org.apache.avalon.framework.component.Component {
 
     public static final String ROLE = HibernateService.class.getName();


diff -riuwBb -x CVS avalon/src/test/net/sf/hibernate/avalon/Labor.hbm.xml avalon-patched/src/test/net/sf/hibernate/avalon/Labor.hbm.xml
--- avalon/src/test/net/sf/hibernate/avalon/Labor.hbm.xml	2003-06-18 15:37:50.000000000 +1000
+++ avalon-patched/src/test/net/sf/hibernate/avalon/Labor.hbm.xml	2003-06-18 15:25:31.000000000 +1000
@@ -1,7 +1,7 @@
 <?xml version="1.0"?>
   <!DOCTYPE hibernate-mapping PUBLIC
-     "-//Hibernate/Hibernate Mapping DTD//EN"
-     "http://hibernate.sourceforge.net/hibernate-mapping.dtd">
+    "-//Hibernate/Hibernate Mapping DTD 2.0//EN" 
+    "http://hibernate.sourceforge.net/hibernate-mapping-2.0.dtd">
 
   <hibernate-mapping>
     <class name="net.sf.hibernate.avalon.Labor" table="LABOR" >




---------------------------------------------------------------------
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-283) Parent class constructor error - prevents compilation of a project

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

The following comment has been added to this issue:

     Author: Les Hazlewood
    Created: Fri, 22 Aug 2003 9:46 AM
       Body:
I was slightly off about the "Grandparent" constructor, as Party has no "PersonName" attribute.  Other than that, the minimal constructor I added does allow complete compilation, so I guess that is what should be generated.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-283
    Summary: Parent class constructor error - prevents compilation of a project
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Les Hazlewood

    Created: Fri, 22 Aug 2003 9:38 AM
    Updated: Fri, 22 Aug 2003 9:39 AM
Environment: all

Description:
A rewrite of the email I wrote after discovering this bug:

I think I've discovered a fairly serious bug with the joined-subclass class generation.  Max Anderson confirmed this sounds like a bug, so I'm adding it to JIRA.

(Please open attached hbm.xml file for reference when reading the rest of this description):

Given the schema, 

a User ISA Person ISA Party ISA DatabaseObject. 

However, the generated code for the User class calls (in its "minimal" 
constructor): 

super(dbCreationTs, emailAddresses, phoneNumbers, postalAddresses, name); 

There is no constructor in the Person class with that signature (however, there is one like that in the Party class, which is the "Grandparent" of User.  The Person class has only one constructor (no minimal constructor), and its signature is: 

Person (Calendar dbCreationTs, Set emailAddresses, Set phoneNumbers,  Set postalAddresses, String gender, PersonName name); 

Therefore, the User class, in its minimal constructor, is trying to call a super constructor that doesn't exist (its actually trying to call a Grandparent constructor). 

I manually typed in a minimal constructor for Person just like the full constructor above, but leaving out gender, since it is nullable. (I believe this is how you generate a "minimal" constructor - leaving out nullable fields - but I could be wrong).  After doing that, everything compiled fine.

Is there a way that an update could be written fairly soon?  Generated class compilation errors is a pretty substantial bug that would affect anyone.  I also can't continue my current project until the correct OO hierarchy is in place and compiles.  I am certainly willing to help out in any way that I can (testing, coding, etc).

Thanks! 

Les Hazlewood 


---------------------------------------------------------------------
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-283) Parent class constructor error - prevents compilation of a project

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

The following issue has been updated:

    Updater: Les Hazlewood (mailto:le...@ha...)
       Date: Fri, 22 Aug 2003 9:39 AM
    Changes:
             Attachment changed to database.hbm.xml
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-283
    Summary: Parent class constructor error - prevents compilation of a project
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Les Hazlewood

    Created: Fri, 22 Aug 2003 9:38 AM
    Updated: Fri, 22 Aug 2003 9:39 AM
Environment: all

Description:
A rewrite of the email I wrote after discovering this bug:

I think I've discovered a fairly serious bug with the joined-subclass class generation.  Max Anderson confirmed this sounds like a bug, so I'm adding it to JIRA.

(Please open attached hbm.xml file for reference when reading the rest of this description):

Given the schema, 

a User ISA Person ISA Party ISA DatabaseObject. 

However, the generated code for the User class calls (in its "minimal" 
constructor): 

super(dbCreationTs, emailAddresses, phoneNumbers, postalAddresses, name); 

There is no constructor in the Person class with that signature (however, there is one like that in the Party class, which is the "Grandparent" of User.  The Person class has only one constructor (no minimal constructor), and its signature is: 

Person (Calendar dbCreationTs, Set emailAddresses, Set phoneNumbers,  Set postalAddresses, String gender, PersonName name); 

Therefore, the User class, in its minimal constructor, is trying to call a super constructor that doesn't exist (its actually trying to call a Grandparent constructor). 

I manually typed in a minimal constructor for Person just like the full constructor above, but leaving out gender, since it is nullable. (I believe this is how you generate a "minimal" constructor - leaving out nullable fields - but I could be wrong).  After doing that, everything compiled fine.

Is there a way that an update could be written fairly soon?  Generated class compilation errors is a pretty substantial bug that would affect anyone.  I also can't continue my current project until the correct OO hierarchy is in place and compiles.  I am certainly willing to help out in any way that I can (testing, coding, etc).

Thanks! 

Les Hazlewood 


---------------------------------------------------------------------
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-283) Parent class constructor error - prevents compilation of a project

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-283
    Summary: Parent class constructor error - prevents compilation of a project
       Type: Bug

     Status: Unassigned
   Priority: Critical

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Les Hazlewood

    Created: Fri, 22 Aug 2003 9:38 AM
    Updated: Fri, 22 Aug 2003 9:38 AM
Environment: all

Description:
A rewrite of the email I wrote after discovering this bug:

I think I've discovered a fairly serious bug with the joined-subclass class generation.  Max Anderson confirmed this sounds like a bug, so I'm adding it to JIRA.

(Please open attached hbm.xml file for reference when reading the rest of this description):

Given the schema, 

a User ISA Person ISA Party ISA DatabaseObject. 

However, the generated code for the User class calls (in its "minimal" 
constructor): 

super(dbCreationTs, emailAddresses, phoneNumbers, postalAddresses, name); 

There is no constructor in the Person class with that signature (however, there is one like that in the Party class, which is the "Grandparent" of User.  The Person class has only one constructor (no minimal constructor), and its signature is: 

Person (Calendar dbCreationTs, Set emailAddresses, Set phoneNumbers,  Set postalAddresses, String gender, PersonName name); 

Therefore, the User class, in its minimal constructor, is trying to call a super constructor that doesn't exist (its actually trying to call a Grandparent constructor). 

I manually typed in a minimal constructor for Person just like the full constructor above, but leaving out gender, since it is nullable. (I believe this is how you generate a "minimal" constructor - leaving out nullable fields - but I could be wrong).  After doing that, everything compiled fine.

Is there a way that an update could be written fairly soon?  Generated class compilation errors is a pretty substantial bug that would affect anyone.  I also can't continue my current project until the correct OO hierarchy is in place and compiles.  I am certainly willing to help out in any way that I can (testing, coding, etc).

Thanks! 

Les Hazlewood 


---------------------------------------------------------------------
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-229) Joined-subclass definitions in separate .hbm.xml

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

The following issue has been updated:

    Updater: Max Rydahl Andersen (mailto:xa...@xa...)
       Date: Fri, 22 Aug 2003 5:17 AM
    Comment:
same patch - just extended with a "secondpass class resolver" for classes that is defined before their superclass is defined.

Also added inheritance cyclic check - just in case i've missed any validity checks ;)


    Changes:
             Attachment changed to noorderingextends.patch
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-229
    Summary: Joined-subclass definitions in separate .hbm.xml
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1 beta 1

   Assignee: 
   Reporter: Duffy Gillman

    Created: Mon, 4 Aug 2003 6:40 PM
    Updated: Fri, 22 Aug 2003 5:17 AM
Environment: All

Description:
Currently all joined-subclass definitions must be contained in the hbm.xml file that defines the superclass.  In application frameworks built on top of Hibernate, this could be very limiting.  In order to allow someone to extend key framework classes, that person must currently edit the configuration files of the framework classes.  It would be very useful to allow new subclasses to be defined in external hbm files.

A new "superclass" attribute could be created for the class element, along with a "inheritanceType=joined|determinant".  When a new hbm file is processed by a DataStore the superclass attribute could be examined and the new class could be treated as a subclass or joined-subclass based on the inheritanceType attribute.  This would place a constraint on the order in which resources are added to the DataStore.  The superclass will need to be added first, or there will have to be a check for completeness of mapping definitions at the point when a SessionFactory is created.


---------------------------------------------------------------------
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-282) JCS: Routing *different* classes to *same* JCS Region causes ClassCastException

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-282
    Summary: JCS: Routing *different* classes to *same* JCS Region causes ClassCastException
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1
             2.0.1
             2.0.2
             2.1 beta 1

   Assignee: 
   Reporter: Bertrand Renuart

    Created: Fri, 22 Aug 2003 5:09 AM
    Updated: Fri, 22 Aug 2003 5:09 AM

Description:
Summary:
--------
Configuring two classes to share the same JCS Region may cause ClassCastException on cache hit.


Description:
------------
By default, Hibernate will use different cache regions for each class, the region name being the class name (class name + property path for collections).
When using the cache config inside hibernate.cfg.xml, it is possible to specify in which region each class should endup. This way, it is possible to direct different classes to the same region.

Internally, Hibernate creates a JCSCache proxy for each class, with a reference to the underlying JCS Region.
If two classes share the same region, then two Hibernate JCSCache proxies are created, both pointing to the same JCS Region.

Object are put and retrieved in/from JCS using a *key*. 
Hibernate uses the persistent ID of the class as key (the Serializable than can be used the load() the object).

Unfortunately, instances of different classes may have the same ID (say a Long if you use the Increment generator). 
If they share the same cache region, one instance will override the other (the cache behaves like a Java Map) - confusing Hibernate on retrieve from cache and causing a ClassCastException (either in your code when casting the return of load(), or inside Hibernate in case of 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-277) hbm2java generates wrong import with BinaryBlobType

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Fri, 22 Aug 2003 4:28 AM
       Body:
Please - supply a very basic hbm.xml + your BlobType with adjusted code for hibernate2 - then i can fix this in minutes, instead of hours ;)

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-277
    Summary: hbm2java generates wrong import with BinaryBlobType 
       Type: Bug

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset

   Assignee: Max Rydahl Andersen
   Reporter: Thomas Jenny

    Created: Thu, 21 Aug 2003 4:31 AM
    Updated: Thu, 21 Aug 2003 8:22 AM
Environment: Hibernate 2.0.2, Hibernate extensions 2.0

Description:
in the mapping file, the following property is defined:

<property
    name="cryptedPassword"
    type="package.BinaryBlobType"
    column="CRYPTED_PASSWORD"
    length="4000"
    />

I'm using the class BinaryBlobType almost as defined at
http://hibernate.bluemars.net/73.html (imports adjusted to 
Hibernate 2)

hbm2java generates the following import:

import byte[];
...

When I remove the import, the code compiles and runs fine; 
but our automatic build cycle is currently broken because of 
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-281) ".class" with <joined-subclass> problem

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-281
    Summary: ".class" with <joined-subclass> problem
       Type: Bug

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: Simone Ricciardi

    Created: Fri, 22 Aug 2003 2:38 AM
    Updated: Fri, 22 Aug 2003 2:38 AM
Environment: windows 2000

Description:
I've acknowledged an error that happens using "select count (*) ..." 
together to a where clause "... where alias.class = ClassName ". 

Suppose to have two classes: 

public class Foo
{
String id;
String attr1;

public String getId(){ return id; }
public void setId(String id){ this.id = id; }
public String getAttr1(){ return attr1; }
public void setAttr1(String attr1){ this.attr1 = attr1; }
}

public class Bar extends Foo
{
String attr2;

public String getAttr2(){ return attr2; }
public void setAttr2(String attr2){ this.attr2 = attr2; }
}

and the corresponding mapping file: 

<hibernate-mapping>
<class name="test.persistents.Foo" table="Foo">
<id name="id" type="string">
<column name="id" length="32"/>
<generator class="uuid.hex"/>
</id>
<property name="attr1" column="attr1" type="string"/>

<joined-subclass name="test.persistents.Bar" table="Bar">
<key column="foo_id"/>
<property name="attr2" column="attr2" type="string"/>
</joined-subclass>
</class>
</hibernate-mapping>

When I try to make the following query: 

Query query = session.createQuery("select count(*) from Foo foo where foo.class = Foo"); 

I get an error of this type:

java.sql.SQLException: General error, message from server: "Unknown table 'foo0__1' in where clause"
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:1651)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:889)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:956)
at com.mysql.jdbc.Connection.execSQL(Connection.java:1874)
at com.mysql.jdbc.PreparedStatement.executeQuery(PreparedStatement.java:1538)
at com.p6spy.engine.logging.P6LogPreparedStatement.executeQuery(P6LogPreparedStatement.java:171)
at net.sf.hibernate.impl.BatcherImpl.getResultSet(BatcherImpl.java:71)
at net.sf.hibernate.loader.Loader.getResultSet(Loader.java:551)
at net.sf.hibernate.loader.Loader.doFind(Loader.java:140)
at net.sf.hibernate.loader.Loader.find(Loader.java:620)
at net.sf.hibernate.hql.QueryTranslator.find(QueryTranslator.java:928)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1343)
at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:76)
at test.Test.main(Test.java:42)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:324)

while if I perform the same query without the select count(*) (select foo from Foo foo where foo.class = Foo) 
all works fine.
Comparing the two queries produced by hibernate in both cases, 
it seems that the error derives from the lack of the "left outer join" with the Bar table in the "from" clause:

with select count(*):
select count(*) as x0_0_ 
from Foo foo0_ 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )

without select count(*):
select foo0_.id as id, 
case when foo0__1.foo_id is not null then 1 
when foo0_.id is not null then 0 end 
as clazz_, 
foo0_.attr1 as attr10_, 
foo0__1.attr2 as attr21_ 
from Foo foo0_ left outer join Bar foo0__1 on foo0_.id=foo0__1.foo_id 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )

in fact the query should be the following:
select count(*) as x0_0_ 
from Foo foo0_ left outer join Bar foo0__1 on foo0_.id=foo0__1.foo_id 
where (case when foo0__1.foo_id is not null then 1 when foo0_.id is not null then 0 end=0 )


---------------------------------------------------------------------
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] =?gb2312?B?IA==?=

[truename <pc...@ne...>]

DQo=

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-267) ObjectNotFoundException is thrown instead of setting the object to null

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

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Mon, 18 Aug 2003 11:41 AM
    Comment:
This is _certainly_ not a bug.

I don't understand the usecase. Why would you not just set both composite id coluumns to null? This seems to make no sense.

I mean, clearly, in a properly designed schema, foreign key constraints are enforced!

Anyway, a workaround would be to either fix your broken relational model of use a custom type. I am inclined to close this issue...
    Changes:
             type changed from Bug
             priority changed from Major
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-267
    Summary: ObjectNotFoundException is thrown instead of setting the object to null
       Type: Improvement

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: abe zafar

    Created: Sat, 16 Aug 2003 1:12 AM
    Updated: Mon, 18 Aug 2003 11:41 AM
Environment: JDK1.4

Description:
Class A is associated with class B by a many-to-one relationship. Class B has a composite primary key which is composed of two columns, these two columns are used as foreign keys in class A. 

Hiberate creates the composite key for class B from the values of these two columns, but when one of the column's value is null the composite key created will not refer to a row in table B. As a result Hibernate throws an ObjectNotFoundException.

I would have expected Hibernate to simply give a value of null for that instance of B instead of throwing the exception.

In a database schema where the foreign key constraints are enforced this would not be a problem, but when that constraint is not present it is definitely a problem.

Is there a workaround to this issue?


---------------------------------------------------------------------
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-271) Filename in err msg in configuration failure

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

The following issue has been updated:

    Updater: Serge Knystautas (mailto:se...@lo...)
       Date: Mon, 18 Aug 2003 9:36 AM
    Comment:
Patch to give filenames in configuration errors and some more detailed info for inter-table dependencies.
    Changes:
             Attachment changed to patch.txt
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-271
    Summary: Filename in err msg in configuration failure
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Serge Knystautas

    Created: Mon, 18 Aug 2003 9:32 AM
    Updated: Mon, 18 Aug 2003 9:36 AM

Description:
I had a lot of trouble debugging my .hbm.xml files because while Hibernate would occasionally give me the line # of the failure, it would not give me the name of the file.  Also, diagnosing foreign-key and other inter-bean dependencies were rather hard, so I made a richer error message for that.


---------------------------------------------------------------------
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-271) Filename in err msg in configuration failure

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-271
    Summary: Filename in err msg in configuration failure
       Type: Patch

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Serge Knystautas

    Created: Mon, 18 Aug 2003 9:32 AM
    Updated: Mon, 18 Aug 2003 9:32 AM

Description:
I had a lot of trouble debugging my .hbm.xml files because while Hibernate would occasionally give me the line # of the failure, it would not give me the name of the file.  Also, diagnosing foreign-key and other inter-bean dependencies were rather hard, so I made a richer error message for that.


---------------------------------------------------------------------
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-270) Ability to choose accessors/ fields/both for population

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-270
    Summary: Ability to choose accessors/ fields/both for population
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Vladimir Dozen

    Created: Sat, 16 Aug 2003 2:46 PM
    Updated: Sat, 16 Aug 2003 2:46 PM
Environment: Any

Description:
Hibernate uses setters/getters to access properties of objects.
This may lead to unconvinience, unstability or performance hit in
various situations. The patch provides ability for programmer to
choose what method will use Hibernate: accessors (default), fields,
accessors-then-fields, fields-then-accessors. Developer may explicitely
mark specific classes as accessible via fields or methods.

Example: unconvinience:

We have a lot of POD structures (i.e. structures which has all
fields as public final) and forcing to provide getters/setters
is just doesn't give any profit and simply unconvinient (BTW: and impossible without removing final).

Example: unstablity:

Often setter contain some code to check validity of the passed
arguments. That's fine when the system that uses Hibernate is the
only way to DB. But, when integrating with legacy systems, we cannot
be sure incorrect data cannot get into DB. When Hibernate attempt then
load such object from the DB using that checking setter, it will get
exception and will fail. The same applies also for multi-row selects and even to loading objects of another types that has (non-lazy) references to broken object. System becomes mostly unusable.

Example: performance:

Validity checks in setters can sometimes take significant amount of
time. For example, time to check if the word exists in some dictionary
grows as log2(n), and can be large enough. Multi-row selects makes the
things even worse.

Workarounds like making alternative set of accessors are ugly, and
make the code messed.

The patch adds hibernate.conf option hibernate.access.order that can
have following values: "accessors-only" (default), "fields-only",
"fields-then-accessors" and "accessors-then-fields". According to
the option Hibernate will scan the object for properties or setters/getter. Plus, using special marker interfaces ReflectHelper.AccessibleViaMethodsOnly, ... programmer can mark specific class as to be accessible using specific method.




---------------------------------------------------------------------
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-270) Ability to choose accessors/ fields/both for population

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

The following issue has been updated:

    Updater: Vladimir Dozen (mailto:vla...@ma...)
       Date: Sat, 16 Aug 2003 2:56 PM
    Comment:
Here is a few tests written to check the functionality.
    Changes:
             Attachment changed to FieldAccessTest.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-270
    Summary: Ability to choose accessors/ fields/both for population
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Vladimir Dozen

    Created: Sat, 16 Aug 2003 2:46 PM
    Updated: Sat, 16 Aug 2003 2:56 PM
Environment: Any

Description:
Hibernate uses setters/getters to access properties of objects.
This may lead to unconvinience, unstability or performance hit in
various situations. The patch provides ability for programmer to
choose what method will use Hibernate: accessors (default), fields,
accessors-then-fields, fields-then-accessors. Developer may explicitely
mark specific classes as accessible via fields or methods.

Example: unconvinience:

We have a lot of POD structures (i.e. structures which has all
fields as public final) and forcing to provide getters/setters
is just doesn't give any profit and simply unconvinient (BTW: and impossible without removing final).

Example: unstablity:

Often setter contain some code to check validity of the passed
arguments. That's fine when the system that uses Hibernate is the
only way to DB. But, when integrating with legacy systems, we cannot
be sure incorrect data cannot get into DB. When Hibernate attempt then
load such object from the DB using that checking setter, it will get
exception and will fail. The same applies also for multi-row selects and even to loading objects of another types that has (non-lazy) references to broken object. System becomes mostly unusable.

Example: performance:

Validity checks in setters can sometimes take significant amount of
time. For example, time to check if the word exists in some dictionary
grows as log2(n), and can be large enough. Multi-row selects makes the
things even worse.

Workarounds like making alternative set of accessors are ugly, and
make the code messed.

The patch adds hibernate.conf option hibernate.access.order that can
have following values: "accessors-only" (default), "fields-only",
"fields-then-accessors" and "accessors-then-fields". According to
the option Hibernate will scan the object for properties or setters/getter. Plus, using special marker interfaces ReflectHelper.AccessibleViaMethodsOnly, ... programmer can mark specific class as to be accessible using specific method.




---------------------------------------------------------------------
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-270) Ability to choose accessors/ fields/both for population

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

The following issue has been updated:

    Updater: Vladimir Dozen (mailto:vla...@ma...)
       Date: Sat, 16 Aug 2003 2:51 PM
    Comment:
Here is the patch for HEAD of Hibernate 2 
made via cvs diff -c
    Changes:
             Attachment changed to hb.diff
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-270
    Summary: Ability to choose accessors/ fields/both for population
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Vladimir Dozen

    Created: Sat, 16 Aug 2003 2:46 PM
    Updated: Sat, 16 Aug 2003 2:51 PM
Environment: Any

Description:
Hibernate uses setters/getters to access properties of objects.
This may lead to unconvinience, unstability or performance hit in
various situations. The patch provides ability for programmer to
choose what method will use Hibernate: accessors (default), fields,
accessors-then-fields, fields-then-accessors. Developer may explicitely
mark specific classes as accessible via fields or methods.

Example: unconvinience:

We have a lot of POD structures (i.e. structures which has all
fields as public final) and forcing to provide getters/setters
is just doesn't give any profit and simply unconvinient (BTW: and impossible without removing final).

Example: unstablity:

Often setter contain some code to check validity of the passed
arguments. That's fine when the system that uses Hibernate is the
only way to DB. But, when integrating with legacy systems, we cannot
be sure incorrect data cannot get into DB. When Hibernate attempt then
load such object from the DB using that checking setter, it will get
exception and will fail. The same applies also for multi-row selects and even to loading objects of another types that has (non-lazy) references to broken object. System becomes mostly unusable.

Example: performance:

Validity checks in setters can sometimes take significant amount of
time. For example, time to check if the word exists in some dictionary
grows as log2(n), and can be large enough. Multi-row selects makes the
things even worse.

Workarounds like making alternative set of accessors are ugly, and
make the code messed.

The patch adds hibernate.conf option hibernate.access.order that can
have following values: "accessors-only" (default), "fields-only",
"fields-then-accessors" and "accessors-then-fields". According to
the option Hibernate will scan the object for properties or setters/getter. Plus, using special marker interfaces ReflectHelper.AccessibleViaMethodsOnly, ... programmer can mark specific class as to be accessible using specific method.




---------------------------------------------------------------------
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-269) TypeFactory typo: "hueristicType"

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-269
    Summary: TypeFactory typo: "hueristicType"
       Type: Improvement

     Status: Unassigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Juergen Hoeller

    Created: Sat, 16 Aug 2003 12:56 PM
    Updated: Sat, 16 Aug 2003 12:56 PM

Description:
TypeFactory has a typo in the method name "heuristicType". Obviously, it should be "heuristicType". Cosmetics, but anyway ;-)


---------------------------------------------------------------------
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-268) java.sql.Connection.getWarning() is not allowed on closed con.

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-268
    Summary: java.sql.Connection.getWarning() is not allowed on closed con.
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.1

   Assignee: 
   Reporter: Avoka

    Created: Sat, 16 Aug 2003 10:25 AM
    Updated: Sat, 16 Aug 2003 10:25 AM

Description:
Index: SessionFactoryImpl.java
===================================================================
RCS file: /cvsroot/hibernate/Hibernate2/src/net/sf/hibernate/impl/SessionFactory
Impl.java,v
retrieving revision 1.26.2.3
diff -r1.26.2.3 SessionFactoryImpl.java
267c267
<
---
>
299,300c299,302
<           JDBCExceptionReporter.logWarnings( conn.getWarnings() );
<           conn.clearWarnings();
---
>           if(!conn.isClosed()) {
>              JDBCExceptionReporter.logWarnings( conn.getWarnings() );
>              conn.clearWarnings();
>           }


---------------------------------------------------------------------
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-267) ObjectNotFoundException is thrown instead of setting the object to null

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-267
    Summary: ObjectNotFoundException is thrown instead of setting the object to null
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core

   Assignee: 
   Reporter: abe zafar

    Created: Sat, 16 Aug 2003 1:12 AM
    Updated: Sat, 16 Aug 2003 1:12 AM
Environment: JDK1.4

Description:
Class A is associated with class B by a many-to-one relationship. Class B has a composite primary key which is composed of two columns, these two columns are used as foreign keys in class A. 

Hiberate creates the composite key for class B from the values of these two columns, but when one of the column's value is null the composite key created will not refer to a row in table B. As a result Hibernate throws an ObjectNotFoundException.

I would have expected Hibernate to simply give a value of null for that instance of B instead of throwing the exception.

In a database schema where the foreign key constraints are enforced this would not be a problem, but when that constraint is not present it is definitely a problem.

Is there a workaround to this issue?


---------------------------------------------------------------------
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-266) Bulk update / batch operations

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-266
    Summary: Bulk update / batch operations
       Type: New Feature

     Status: Unassigned
   Priority: Major

    Project: Hibernate2

   Assignee: 
   Reporter: Michael Schechter

    Created: Fri, 15 Aug 2003 10:39 PM
    Updated: Fri, 15 Aug 2003 10:39 PM
Environment: N/A

Description:
In working with Hibernate, I have had the need to execute high-performance bulk updates. Without the concept of an equivalent to the SQL UPDATE statement, I was forced to fall back to obtaining a PreparedStatement on a connection to execute the hand-coded SQL directly. I see this as a problem, as there is no way to protect this code from changes in the table names, column names, or object relationships the way we can with other operations in Hibernate.

A typical statement that would fit the above description would be:
UPDATE MY_TABLE
SET COL_1="A"
WHERE COL_1="B";

There is always the possibility that iterating over the matching object set and committing the transaction through Hibernate would be comparable. It seems counterintuitive that creating a large number of row updates could possibly be as fast as a single statement executed on the database server.


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