hibernate-issues — Hibernate JIRA Notifications

[Hibernate-issues] [Hibernate-JIRA] Closed: (HB-243) Polymorphic associations are not handled properly

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

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Sun, 10 Aug 2003 12:04 PM

I have updated hbm2java in CVS to handle this.

It now has the <meta attribute="property-type">com.hp.Printer</meta> support which can be used with <any> tags.

And it also has new support for <meta attribute="interface">true</meta> which can
be used to generated interfaces instead of concrete classes from the hbm.xml files.

Please try it out and inform me if you find any uncovered combinations I havent thought of ;)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-243
    Summary: Polymorphic associations are not handled properly
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             toolset
   Fix Fors:
             2.1
   Versions:
             2.0 final

   Assignee: Max Rydahl Andersen
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:54 AM
    Updated: Sun, 10 Aug 2003 12:04 PM
Environment: JDK1.4

Description:
If I have an association like this one:

<many-to-one classname="com.hp.Printer"/>

and Printer does not have a mapping but it is an interface for a class called com.hp.ColorPrinter that does have a mapping, I would get two methods generated as I would expect:

public void setPrinter( Printer printer ) {
  ...
}

public Printer getPrinter() {
  ...
}

But since "com.hp.Printer" was never mapped I would get a rutime exception saying cannot find the mapping. If through some other tag or the <many-to-one> tag itself I can indicate that use the interface type for code generation but use the implementation class to look for the mapping the problem would be solved. For example if we had something like this:

<many-to-one compile-time-class="com.hp.Printer" run-time-class="com.hp.ColorPrinter"/> then the setter and getter would be generated using the compile-time-class and the run-time-class would be used to look up the mapping at runtime.



---------------------------------------------------------------------
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-243) Polymorphic associations are not handled properly

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

Message:

   The following issue has been re-assigned.

   Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
   Assigner: Gavin King (mailto:ga...@in...)
       Date: Sun, 10 Aug 2003 9:02 AM
    Comment:
Max?
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-243
    Summary: Polymorphic associations are not handled properly
       Type: Improvement

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0 final

   Assignee: Max Rydahl Andersen
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:54 AM
    Updated: Sun, 10 Aug 2003 9:02 AM
Environment: JDK1.4

Description:
If I have an association like this one:

<many-to-one classname="com.hp.Printer"/>

and Printer does not have a mapping but it is an interface for a class called com.hp.ColorPrinter that does have a mapping, I would get two methods generated as I would expect:

public void setPrinter( Printer printer ) {
  ...
}

public Printer getPrinter() {
  ...
}

But since "com.hp.Printer" was never mapped I would get a rutime exception saying cannot find the mapping. If through some other tag or the <many-to-one> tag itself I can indicate that use the interface type for code generation but use the implementation class to look for the mapping the problem would be solved. For example if we had something like this:

<many-to-one compile-time-class="com.hp.Printer" run-time-class="com.hp.ColorPrinter"/> then the setter and getter would be generated using the compile-time-class and the run-time-class would be used to look up the mapping at runtime.



---------------------------------------------------------------------
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-243) Polymorphic associations are not handled properly

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

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Sun, 10 Aug 2003 9:01 AM
    Comment:
This is not a bug, it is a missing (?) feature from the hbm2java tool.

It would be implemented as a <meta name="property-type">com.hp.Printer</meta>
    Changes:
             type changed from Bug
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-243
    Summary: Polymorphic associations are not handled properly
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0 final

   Assignee: 
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:54 AM
    Updated: Sun, 10 Aug 2003 9:01 AM
Environment: JDK1.4

Description:
If I have an association like this one:

<many-to-one classname="com.hp.Printer"/>

and Printer does not have a mapping but it is an interface for a class called com.hp.ColorPrinter that does have a mapping, I would get two methods generated as I would expect:

public void setPrinter( Printer printer ) {
  ...
}

public Printer getPrinter() {
  ...
}

But since "com.hp.Printer" was never mapped I would get a rutime exception saying cannot find the mapping. If through some other tag or the <many-to-one> tag itself I can indicate that use the interface type for code generation but use the implementation class to look for the mapping the problem would be solved. For example if we had something like this:

<many-to-one compile-time-class="com.hp.Printer" run-time-class="com.hp.ColorPrinter"/> then the setter and getter would be generated using the compile-time-class and the run-time-class would be used to look up the mapping at runtime.



---------------------------------------------------------------------
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-242) <meta attribute="implements"> does not behave as expected

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

Message:

   The following issue has been closed.

   Resolver: Max Rydahl Andersen
       Date: Sun, 10 Aug 2003 6:37 AM

This is intentional to have the <meta> tag uniformily be inherited by nested tags.
To avoid having the implements tag "inherit" further down you just add an attribute inherit="false" on it - then it will not be inherited down to composite id's.

I know the default inheritance of meta sometimes causes "funny" effects - but we have made the inheritance "rule" as simple as possible (namely: "ALWAYS inherit meta, except if inherit=false") thus you get the easy feature of just saying: <meta attribute="scope-field">protected</meta> just ONCE in the hbm.xml.

But if you got more "complex" hbm.xml files then you'll have to be more explicit about it.....hope ya' understand ;)

/max

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-242
    Summary: <meta attribute="implements"> does not behave as expected
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.1

   Assignee: 
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:40 AM
    Updated: Sun, 10 Aug 2003 6:37 AM
Environment: JDK1.4

Description:
If the tag <meta attribute="implements">com.hp.Printer</meta> is inserted as a child of the class tag it properly adds the implement clause to the class. But if that class also contained a <composite-id> tag which indicated a class then that class would also UNEXPECTEDLY implement the interface "com.hp.Printer".


So in the following example:

<class name="com.hp.ColorPrinter">
<meta attribute="implements">com.hp.Printer</meta> 
<composite-id
        name="propertyName"
        class="com.hp.PrinterId">

        <key-property name="propertyName" type="typename" column="column_name"/>
        <key-many-to-one name="propertyName class="ClassName" column="column_name"/>
</composite-id>

Both "ColorPrinter" and "PrinterId" end up implementing "com.hp.Printer". ColorPrinter is expected to implement the interface, but PrinterId should not implement the interface.
        






---------------------------------------------------------------------
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-239) javadoc build spits >200 warnings

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

Message:

   The following issue has been closed.

   Resolver: Christian Bauer
       Date: Sun, 10 Aug 2003 6:14 AM

All fixed and comitted. Everyone keep an eye on their "first sentence" in the Javadocs. If you're in trouble, read my last comment :)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-239
    Summary: javadoc build spits >200 warnings
       Type: Bug

     Status: Closed
   Priority: Trivial
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.2

   Assignee: Christian Bauer
   Reporter: Gavin King

    Created: Thu, 7 Aug 2003 7:43 AM
    Updated: Sun, 10 Aug 2003 6:14 AM
Environment: Ant build

Description:
The javadoc build currently spits many warnings, all the same.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Commented: (HB-232) Custom types cannot be uses for ids with indentity and sequence generators

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

The following comment has been added to this issue:

     Author: Max Rydahl Andersen
    Created: Sun, 10 Aug 2003 5:29 AM
       Body:
Could we try to find an alternative solution for this one ?

I've got a similar problem with legacy generated version/timestamps (it's a byte[8]) that would be great if Hibernate could integrate with.

A last resort would be to add ExtendedUserType or something.


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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-232
    Summary: Custom types cannot be uses for ids with indentity and sequence generators
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: James Lewis

    Created: Tue, 5 Aug 2003 9:37 AM
    Updated: Fri, 8 Aug 2003 11:40 PM
Environment: Any environment.  MySql DB

Description:
All of my persistent objects have a custom primary key object.  

For instance, my Part object has a PartID as the key.  This allows me to perform compile time type checking in my service layer.

I was ably to create a UserType that converted the coulmn type of integer to PartID.  No problem, it worked great.  However, the IdentityGeneratorFactory throw an exception because my custom types return PartID.class as the return type.  The IdentityGeneratorFactory's 'get' method only takes classes that are of type Integer.class, Long.class, and Short.class.  The API should be changed so that the get method returns a Serializable instead of a Number, and takes a Type instead of a class.  This would allow the IdentityGeneratorFactory to return the custom class type.

What are your thoughts.

James


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

[Jiri C. <ko...@ch...>]

I am newbie in Hibernate and I want to use with JBoss. I was red 
/66.html, but when I was start JBoss it told that
00:22:48,829 INFO [Configuration] Configuration resource: 
/hibernate.cfg.xml
00:22:48,871 WARN [Configuration] /hibernate.cfg.xml not found

in manual I red that everything must be in /META-INF/jboss-service.xml 
so I do not understand why this. Does anyone help?

Thanks

[Hibernate-issues] [Hibernate-JIRA] Created: (HB-243) Polymorphic associations are not handled properly

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-243
    Summary: Polymorphic associations are not handled properly
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0 final

   Assignee: 
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:54 AM
    Updated: Sun, 10 Aug 2003 2:54 AM
Environment: JDK1.4

Description:
If I have an association like this one:

<many-to-one classname="com.hp.Printer"/>

and Printer does not have a mapping but it is an interface for a class called com.hp.ColorPrinter that does have a mapping, I would get two methods generated as I would expect:

public void setPrinter( Printer printer ) {
  ...
}

public Printer getPrinter() {
  ...
}

But since "com.hp.Printer" was never mapped I would get a rutime exception saying cannot find the mapping. If through some other tag or the <many-to-one> tag itself I can indicate that use the interface type for code generation but use the implementation class to look for the mapping the problem would be solved. For example if we had something like this:

<many-to-one compile-time-class="com.hp.Printer" run-time-class="com.hp.ColorPrinter"/> then the setter and getter would be generated using the compile-time-class and the run-time-class would be used to look up the mapping at runtime.



---------------------------------------------------------------------
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-242) <meta attribute="implements"> does not behave as expected

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-242
    Summary: <meta attribute="implements"> does not behave as expected
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.1

   Assignee: 
   Reporter: abe zafar

    Created: Sun, 10 Aug 2003 2:40 AM
    Updated: Sun, 10 Aug 2003 2:40 AM
Environment: JDK1.4

Description:
If the tag <meta attribute="implements">com.hp.Printer</meta> is inserted as a child of the class tag it properly adds the implement clause to the class. But if that class also contained a <composite-id> tag which indicated a class then that class would also UNEXPECTEDLY implement the interface "com.hp.Printer".


So in the following example:

<class name="com.hp.ColorPrinter">
<meta attribute="implements">com.hp.Printer</meta> 
<composite-id
        name="propertyName"
        class="com.hp.PrinterId">

        <key-property name="propertyName" type="typename" column="column_name"/>
        <key-many-to-one name="propertyName class="ClassName" column="column_name"/>
</composite-id>

Both "ColorPrinter" and "PrinterId" end up implementing "com.hp.Printer". ColorPrinter is expected to implement the interface, but PrinterId should not implement the interface.
        






---------------------------------------------------------------------
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-232) Custom types cannot be uses for ids with indentity and sequence generators

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Sun, 10 Aug 2003 12:11 AM
       Body:
Ugh. I had to roll back this change. It broke on some platforms.


This is not going to be possible, w/o changes to the UserType and CompositeUserType interfaces.

So its out :(

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-232
    Summary: Custom types cannot be uses for ids with indentity and sequence generators
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: James Lewis

    Created: Tue, 5 Aug 2003 9:37 AM
    Updated: Fri, 8 Aug 2003 11:40 PM
Environment: Any environment.  MySql DB

Description:
All of my persistent objects have a custom primary key object.  

For instance, my Part object has a PartID as the key.  This allows me to perform compile time type checking in my service layer.

I was ably to create a UserType that converted the coulmn type of integer to PartID.  No problem, it worked great.  However, the IdentityGeneratorFactory throw an exception because my custom types return PartID.class as the return type.  The IdentityGeneratorFactory's 'get' method only takes classes that are of type Integer.class, Long.class, and Short.class.  The API should be changed so that the get method returns a Serializable instead of a Number, and takes a Type instead of a class.  This would allow the IdentityGeneratorFactory to return the custom class type.

What are your thoughts.

James


---------------------------------------------------------------------
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-227) NamingStrategy / prefix support for database objects

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Sat, 9 Aug 2003 7:14 PM
       Body:
Looks good to me. :)
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-227
    Summary: NamingStrategy / prefix support for database objects
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Timo Verhoeven

    Created: Mon, 4 Aug 2003 6:29 AM
    Updated: Mon, 4 Aug 2003 6:29 AM

Description:
Initial feature idea from mailing list:

Hi all!

When I design database datamodels I usually encounter clashes between 
reserved names and names I'd like to use for my tables/columns, e.g. 
"user", "role", etc.. So I ended up prefixing all tables/views/columns: 
Tables have a "tbl" prefix, views a "qry" prefix and columns either 
have a "fld" or a prefix based on the datatype ("txt"/"str" for 
varchars, etc.).

I like to keep my mapping files small (/ to have few xdoclet tags) and 
like the fact that hibernate has smart default for column names: it 
uses the property's name. 

Would it be possible/would you consider it useful to be able to specify 
"default prefixes" for tables/columns so that I don't have to name my 
columns manually in my mappings when I have to use prefixes? Such 
settings could go into the SessionFactory configuration. 


Opinions?

Timo


---------------------------------------------------------------------
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-241) cached collection depends on closed Session

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 7:12 PM

This is now fixed in v21branch in CVS.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Closed
   Priority: Major
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Sat, 9 Aug 2003 7:12 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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-54) Flexible Interceptor Assignment

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 9:08 AM

A session should never, ever be re-used by a new user. Its lifetime should be much shorter than a HttpSession. I can't think of a good usecase for this and it is anyway possible to manipulate the Interceptor by keeping a reference to it.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-54
    Summary: Flexible Interceptor Assignment
       Type: New Feature

     Status: Closed
   Priority: Minor
 Resolution: REJECTED

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0rc2
             2.1

   Assignee: Gavin King
   Reporter: Christian Bauer

    Created: Mon, 5 May 2003 9:19 AM
    Updated: Sat, 9 Aug 2003 9:08 AM

Description:
Interceptors are currently only assignable via SessionFactory configuration or Session creation (constructor parameter). This is not flexible enough for an application with Session Disconnection, e.g. while using the AuditInfo Interceptor Pattern:

- a Session is created with a new interceptor, the current user is passed as a parameter to the interceptor

- the Session will be disconnected/reconnected multiple times

- the user's id may change (logout/login/relogin/...), there's no way to pass a new interceptor to an existing Session or to modify/recall the existing interceptor

An Interceptor should be handled more dynamically, like with getInterceptor()/setInterceptor() methods of the Session. Is this possible or is the Interceptor required at Session instantiation?


---------------------------------------------------------------------
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-206) Fieldname constants generator, and Http form loader utility.

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

Message:

   The following issue has been re-assigned.

   Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
   Assigner: Gavin King (mailto:ga...@in...)
       Date: Sat, 9 Aug 2003 9:05 AM
    Comment:
Max, I'll let you decide if this is a Good Thing.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-206
    Summary: Fieldname constants generator, and Http form loader utility.
       Type: Patch

     Status: Assigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.2

   Assignee: Max Rydahl Andersen
   Reporter: Matt Hall

    Created: Mon, 21 Jul 2003 12:38 PM
    Updated: Sat, 9 Aug 2003 9:05 AM

Description:
This is a modification to BasicRenderer to generate a series of constants at the top of generated hibernate data objects that represent each property contained in the object.  Looks something like:

    public static String FIELD_ID = "com.whatever.Category.id";
    public static String FIELD_TYPE = "com.whatever.Category.type";
    public static String FIELD_TITLE = "com.whateverCategory.title";

If you then use these constants to name your fields in a web form, you can use the other part of this submissions, HttpFormUtil, to load your hibernate data objects from an HttpServletRequest automatically via reflection.



---------------------------------------------------------------------
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-206) Fieldname constants generator, and Http form loader utility.

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

The following issue has been updated:

    Updater: Gavin King (mailto:ga...@in...)
       Date: Sat, 9 Aug 2003 9:04 AM
    Comment:
This is actually a patch!
    Changes:
             type changed from Improvement
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-206
    Summary: Fieldname constants generator, and Http form loader utility.
       Type: Patch

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             toolset
   Versions:
             2.0.2

   Assignee: 
   Reporter: Matt Hall

    Created: Mon, 21 Jul 2003 12:38 PM
    Updated: Sat, 9 Aug 2003 9:04 AM

Description:
This is a modification to BasicRenderer to generate a series of constants at the top of generated hibernate data objects that represent each property contained in the object.  Looks something like:

    public static String FIELD_ID = "com.whatever.Category.id";
    public static String FIELD_TYPE = "com.whatever.Category.type";
    public static String FIELD_TITLE = "com.whateverCategory.title";

If you then use these constants to name your fields in a web form, you can use the other part of this submissions, HttpFormUtil, to load your hibernate data objects from an HttpServletRequest automatically via reflection.



---------------------------------------------------------------------
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-28) supporting mapping to ldap repositories

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 8:59 AM

This is *ancient* and I'm closing it, because I don't think this will ever be a priority.

It is possible now, with a custom ClassPersister.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-28
    Summary: supporting mapping to ldap repositories
       Type: New Feature

     Status: Closed
   Priority: Minor
 Resolution: WON'T FIX

    Project: Hibernate2

   Assignee: 
   Reporter: Max Rydahl Andersen

    Created: Sat, 3 May 2003 10:16 AM
    Updated: Sat, 9 Aug 2003 8:59 AM

Description:
supporting mapping to ldap repositories
are there any plans to add support for mapping to ldap 
based data repositories ? 

http://sourceforge.net/tracker/index.php?func=detail&aid=686571&group_id=40712&atid=428711


---------------------------------------------------------------------
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-164) Temporary tables

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 8:55 AM

I don't really fully understand what is being propsed here, but it looks like something that is easily addressed by the new SQL query functionality.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-164
    Summary: Temporary tables
       Type: New Feature

     Status: Closed
   Priority: Minor
 Resolution: WON'T FIX

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: Christian Bauer

    Created: Tue, 8 Jul 2003 3:44 PM
    Updated: Sat, 9 Aug 2003 8:55 AM

Description:
Many dbms provide the ability to create and manage temporary tables that have some level of
optimization, like being kept in memory. I know this is not related to or-mapping, but I see
Hibernate as something more than just or-mapping: it's a tool that raises the ability to
write database independent applications in a more transparent way.
 What do I need temp tables for? Consider a complex query that provides
 a result that's needed in other queries but for performance reasons you don't want to run
this query as a subquery again and again. On the other side, keeping the result in memory is
not efficient as well, think about  something like select ... from ... where id in (...)
where the content of the in clause is the result of the above query: it's definitely easy to
go over the maximum statement length, while this query can be more efficiently expressed
thru a subquery or a join with the temp table.
 
 For the moment I've created a persistent table to put the query result in, but this way you
need to know how many temp tables you need at design time or add a selection column... not
as handy as a temporary table that can be created at run time and has special handling by
the database.


---------------------------------------------------------------------
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-172) multiple discriminator-value for subclass

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Sat, 9 Aug 2003 8:51 AM
       Body:
Tom, this is kinda nice ....


.... any chance you could post this as a patch? I might consider working it in somehow.

We might need to "genericize" it a bit first.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-172
    Summary: multiple discriminator-value for subclass
       Type: New Feature

     Status: Unassigned
   Priority: Minor

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Ludovic Orban

    Created: Thu, 10 Jul 2003 1:59 AM
    Updated: Thu, 10 Jul 2003 1:59 AM
Environment: any/all

Description:
It would be nice to allow a class or a subclass to have multiple possible discriminator values.

Hibernate would need to map the same subclass to multiple values and the resulting unmapped values to the root class (or some other subclass), using a mapping that could look like this:


<class name="pkg.RootObject" table="SOME_TABLE" discriminator-value="*">

...

    <discriminator column="TYPE" type="integer" />

...

    <subclass name="pkg.SubClassA" discriminator-value="12, 13">



    <subclass name="pkg.SubClassB" discriminator-value="45">

</class>



---------------------------------------------------------------------
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-235) Add a count() method on the Criteria interface

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 8:45 AM

This is a dupe of HB-143.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-235
    Summary: Add a count() method on the Criteria interface
       Type: New Feature

     Status: Closed
   Priority: Major
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: 
   Reporter: Sebastien Cesbron

    Created: Wed, 6 Aug 2003 4:05 AM
    Updated: Sat, 9 Aug 2003 8:45 AM

Description:
It would be very convenient to have a count() method on the Criteria interface. Thus it would be possible to know the total size of a list when you don't want to load all the elements.

Example :

Criteria criteria = session.createCriteria(User.class);
criteria.setFirstResult(0);
criteria.setMaxResult(10);

// Custom class that holds a page of the list and the total size
Page page = new Page();
page.setList(criteria.list());
page.setTotalSize(criteria.count());
___________________________^^^^^^^ => the new 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] Closed: (HB-160) Batch Reading

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 8:43 AM

This was already implemented.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-160
    Summary: Batch Reading
       Type: New Feature

     Status: Closed
   Priority: Minor
 Resolution: DUPLICATE

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0.1

   Assignee: 
   Reporter: Christian Bauer

    Created: Tue, 8 Jul 2003 3:39 PM
    Updated: Sat, 9 Aug 2003 8:43 AM

Description:
Feature is used to reduce # queries sent to the database to retrieve related lazily
initialized 1-1's.  Example:  Retrieve 20 Contact objects, each has a 1-1 to an Account. 
Initial Query just asked to retrieve the Contact objects with nothing else being built
initially.  If each Contact works for a different Account, then if I call getAccount on each
Contact (with initially empty cache), what started as 1 query turns into 21 queries (one PK
query for each Account).
 
 Feature supports the ability for those lazy Account references to "remember" what their
"originating query" was - the one used to retrieve the 20 Contact objects in the first
place.  Then, when the first Contact's "account" reference is initialized, it joins with the
originating query's criteria to get all of the related accounts that match the originating
query's criteria, populating the cache with 20 Account objects with one query.  Now, what
would otherwise be 21 queries is now just 2 (1 for the 20 Contacts, and 1 for the 20
Accounts).
 
 Example:
 
 originating query:  select * from contact where last_name = 'Smith'
 
 Then, when the first uninitialized Contact.account reference is initialized (from that set
of Contacts), the account query is:
 
 select t0.* from account t0, contact t1 where t1.account_id = t0.account_id and
t1.last_name = 'Smith'


---------------------------------------------------------------------
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-32) Embeded Native SQL in HQL

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Sat, 9 Aug 2003 7:13 AM

I think the new createSQLQuery() functionality is a better solution to this problem.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-32
    Summary: Embeded Native SQL in HQL
       Type: Improvement

     Status: Closed
   Priority: Major
 Resolution: REJECTED

    Project: Hibernate2
   Fix Fors:
             2.1 beta 1

   Assignee: Gavin King
   Reporter: Max Rydahl Andersen

    Created: Sat, 3 May 2003 10:19 AM
    Updated: Sat, 9 Aug 2003 7:13 AM

Description:
Embeded Native SQL in HQL
It will be nice to be able to embed native SQL in HQL. 
By example we use Oracle connect by/starts with 
clauses in SQL for retrive flat items from tree and some 
predefined views. But it is not possible to use them in 
HQL. Can you simple left all between <sql> and </sql> 
unchanged? 

Translate something like: 

from x in XClass 
where x.name like ? 
and x.id in <sql>( 
select id from XTable 
connect by prior id = parent_id 
starts with id = ? 
)</sql> 

TO: 

SELECT ... FROM XTable as X WHERE X.name like ? 
and ( 
select id from XTable 
connect by prior id = parent_id 
starts with id = ? 
) 

It mustn't be difficult, isn't it? 

OR even more : 

<sql>select a, b, c FROM T</sql> 
TO: 
select a, b, c, FROM T 

OR even more : 

select a.ad, <sql>getBestPrice(${a.id}, ${a.owner.id}) 
</sql> from a in class AAA; 

TRANSLATES TO: 

select a.id as f1, getBestPrice(a.id, e.id) as f2 
from Article a, Enterprise e 
where a.owner_id = e.id; 

where getPestPrice is a SQL server function. 

With best regards! 
Dmitry M.Ivlev 

http://sourceforge.net/tracker/index.php?func=detail&aid=711287&group_id=40712&atid=428711


---------------------------------------------------------------------
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-232) Custom types cannot be uses for ids with indentity and sequence generators

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

Message:

   The following issue has been closed.

   Resolver: Gavin King
       Date: Fri, 8 Aug 2003 11:40 PM

Done.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-232
    Summary: Custom types cannot be uses for ids with indentity and sequence generators
       Type: Improvement

     Status: Closed
   Priority: Minor
 Resolution: FIXED

    Project: Hibernate2
 Components: 
             core
   Fix Fors:
             2.1 beta 1
   Versions:
             2.0rc2

   Assignee: Gavin King
   Reporter: James Lewis

    Created: Tue, 5 Aug 2003 9:37 AM
    Updated: Fri, 8 Aug 2003 11:40 PM
Environment: Any environment.  MySql DB

Description:
All of my persistent objects have a custom primary key object.  

For instance, my Part object has a PartID as the key.  This allows me to perform compile time type checking in my service layer.

I was ably to create a UserType that converted the coulmn type of integer to PartID.  No problem, it worked great.  However, the IdentityGeneratorFactory throw an exception because my custom types return PartID.class as the return type.  The IdentityGeneratorFactory's 'get' method only takes classes that are of type Integer.class, Long.class, and Short.class.  The API should be changed so that the get method returns a Serializable instead of a Number, and takes a Type instead of a class.  This would allow the IdentityGeneratorFactory to return the custom class type.

What are your thoughts.

James


---------------------------------------------------------------------
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-241) cached collection depends on closed Session

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

The following comment has been added to this issue:

     Author: Gavin King
    Created: Fri, 8 Aug 2003 8:43 PM
       Body:
OK, interesting. This is a problem affecting the combination of <key-many-to-one> and <jcs-cache>. The problem is that EntityType.disassemble() just returnins the id (it doesn't try to disassemble the id). I think its easy to fix by just changing EntityType.diassemble()/assemble().

(I didn't really need the teast case after all; all I needed to know was that you were using a <key-many-to-one>!)

Thanks.
---------------------------------------------------------------------
View the issue:

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Fri, 8 Aug 2003 6:59 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


---------------------------------------------------------------------
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-239) javadoc build spits >200 warnings

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

The following comment has been added to this issue:

     Author: Christian Bauer
    Created: Fri, 8 Aug 2003 7:07 PM
       Body:
We have two levels of errors here:

- Warnings reported by the "first sentence" detector of the JavaDoc generator. 

- Errors in the JavaDoc (wrong parameter names, missing tags) detected by IntelliJ inspector, no warnings in generator.

I fixed all of the generator warnings by tricking the "first sentence" detection. I've to commit about 30 files from the src/ directory. This stuff is really crazy:

/**
 * A first sentence.
 * @param foo
 */

This is broken. Whenever you use a first sentence (detected by: first period with trailing space, new line or first tag), you have to add a second sentence if a tag is following.

/**
 * A first sentence. This is for JavaDoc.
 * @param foo
 */

This works. Don't use questionmarks to end the first sentence. If you only have a single sentence, don't include parameters, exceptions and return tags. Don't end first sentences in the next line:


/**
 * This is a broken
 * first sentence. It will produce a warning.
 * @param foo
 */

Oh well. IntelliJ (use it!) detects all of the JavaDoc errors  but doesn't check the "first sentence" algorithm. I've also found some strange behaviour if you include a questionmark _anywhere_ in the first sentence. Don't do it.

I'll commit the changes on request. We still have a couple of hundred non-warning (but real) errors to fix. Everyone use a good IDE and fix this while working with the source. I won't spent three days for this :)

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-239
    Summary: javadoc build spits >200 warnings
       Type: Bug

     Status: Assigned
   Priority: Trivial

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.2

   Assignee: Christian Bauer
   Reporter: Gavin King

    Created: Thu, 7 Aug 2003 7:43 AM
    Updated: Thu, 7 Aug 2003 7:43 AM
Environment: Ant build

Description:
The javadoc build currently spits many warnings, all the same.


---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

[Hibernate-issues] [Hibernate-JIRA] Updated: (HB-241) cached collection depends on closed Session

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

The following issue has been updated:

    Updater: John Kristian (mailto:jkr...@do...)
       Date: Fri, 8 Aug 2003 6:59 PM
    Comment:
Here is a test case.  See README.txt to start with.
    Changes:
             Attachment changed to tests.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

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

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

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


Here is an overview of the issue:
---------------------------------------------------------------------
        Key: HB-241
    Summary: cached collection depends on closed Session
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Hibernate2
 Components: 
             core
   Versions:
             2.0.1

   Assignee: 
   Reporter: John Kristian

    Created: Fri, 8 Aug 2003 6:48 PM
    Updated: Fri, 8 Aug 2003 6:59 PM
Environment: Windows XP, JBoss 3, Microsoft SQL Server

Description:
There's a problem with a collection in the JCS cache that contains entities whose composite-id contains a reference to an entity that contains a lazy collection.  An exception 'Failed to lazily initialize a collection - no Session' is thrown when attempting to initialize a lazy collection member of an entity referred to by the composite-id of an entity contained in a collection from the JCS cache, if the cached collection was loaded (and cached) by a Session that is now closed.

An exception should not be thrown, in this case.  The lazy collection should be initialized using the Session that found the cached collection.

It appears (although I'm not entirely certain) that composite-ids from the cached collection contain references to entities that were loaded by a previous Session (that missed the JCS cache) which is now closed.  This seems erroneous, to me; I think such a composite-id should contain references to entities in the current Session (that hit the JCS cache).

To work around this problem, I intend to make the setId method of my entities check the references (if any) in the new id and replace them, if necessary, with references to objects with the same id but in the same Session as the containing entity.  Critique and better ideas are welcome <mailto:jkr...@do...>.

I have a tolerably small test case, which I'll attach to this issue if I can figure out how.  (I'm not familiar with JIRA.)


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