Menu
▾
▴
hibernate-issues — Hibernate JIRA Notifications
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(32) |
Jun
(175) |
Jul
(209) |
Aug
(302) |
Sep
(287) |
Oct
(339) |
Nov
(314) |
Dec
(329) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(479) |
Feb
(389) |
Mar
(599) |
Apr
(307) |
May
(390) |
Jun
(300) |
Jul
(410) |
Aug
(458) |
Sep
(299) |
Oct
(315) |
Nov
(363) |
Dec
(529) |
| 2005 |
Jan
(568) |
Feb
(434) |
Mar
(1004) |
Apr
(823) |
May
(767) |
Jun
(763) |
Jul
(854) |
Aug
(862) |
Sep
(560) |
Oct
(853) |
Nov
(763) |
Dec
(731) |
| 2006 |
Jan
(776) |
Feb
(608) |
Mar
(657) |
Apr
(424) |
May
(559) |
Jun
(440) |
Jul
(448) |
Aug
(58) |
Sep
|
Oct
(17) |
Nov
(16) |
Dec
(8) |
| 2007 |
Jan
(1) |
Feb
(8) |
Mar
(2) |
Apr
(5) |
May
(3) |
Jun
(3) |
Jul
(3) |
Aug
(16) |
Sep
(10) |
Oct
(4) |
Nov
(4) |
Dec
(4) |
| 2008 |
Jan
(8) |
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
|
From: <leg...@at...> - 2003-11-24 05:28:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HBI-18 Here is an overview of the issue: --------------------------------------------------------------------- Key: HBI-18 Summary: Unable to generate any hbm.xml file Type: Bug Status: Unassigned Priority: Major Project: Hibernate 1.2 Assignee: Reporter: Herve Tchepannou Created: Sun, 23 Nov 2003 11:28 PM Updated: Sun, 23 Nov 2003 11:28 PM Environment: RedHat 9.0 JDK-1.4.02 Description: Im unable to generate the hbm.xml files using hibernate tools --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-24 01:46:25
|
The following issue has been updated:
Updater: Dmitry (mailto:hib...@di...)
Date: Sun, 23 Nov 2003 7:44 PM
Comment:
The sources
Changes:
Attachment changed to sources.zip
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-494&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-494
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-494
Summary: lazy collection loading causes ConcurrentModificationException
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Dmitry
Created: Sun, 23 Nov 2003 7:44 PM
Updated: Sun, 23 Nov 2003 7:44 PM
Environment: Windows XP Pro, JDK 1.3.1_09, Oracle database 8.1.7.4
Description:
Attempt to access lazy collection throws an exception:
[ERROR] PersistentCollection - -Failed to lazily initialize a collection <java.util.ConcurrentModificationException>java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.remove(HashMap.java:755)
Attached sources contain all necessary to run test. You will need Oracle JDBC.
1. Create new database user (optional, you may use existing schema)
2. execute init.sql from sources archive on the database
3. fix Test.java (HOSTNAME, SID, USERNAME and PASSWORD in the JDBC database URL).
4. Run test
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-24 01:44:25
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-494 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-494 Summary: lazy collection loading causes ConcurrentModificationException Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Reporter: Dmitry Created: Sun, 23 Nov 2003 7:44 PM Updated: Sun, 23 Nov 2003 7:44 PM Environment: Windows XP Pro, JDK 1.3.1_09, Oracle database 8.1.7.4 Description: Attempt to access lazy collection throws an exception: [ERROR] PersistentCollection - -Failed to lazily initialize a collection <java.util.ConcurrentModificationException>java.util.ConcurrentModificationException at java.util.HashMap$HashIterator.remove(HashMap.java:755) Attached sources contain all necessary to run test. You will need Oracle JDBC. 1. Create new database user (optional, you may use existing schema) 2. execute init.sql from sources archive on the database 3. fix Test.java (HOSTNAME, SID, USERNAME and PASSWORD in the JDBC database URL). 4. Run test --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-24 01:18:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sun, 23 Nov 2003 7:18 PM
Body:
I don't like this idea. It sounds like bloat. People just need to learn what the default behavior is.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-489
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-489
Summary: Let the user specify wether inherit is default false or true
Type: Improvement
Status: Open
Priority: Major
Project: Hibernate2
Components:
toolset
Assignee: Max Rydahl Andersen
Reporter: Max Rydahl Andersen
Created: Sat, 22 Nov 2003 6:17 AM
Updated: Sun, 23 Nov 2003 7:18 PM
Description:
"More and more people" reports that the default inherit strategy for <meta> sometimes conflict with their intentions. e.g. because all meta is inherited by default will meta="implements" in a class be applied to all nested <component> etc.
The current workaround is to set inherit="false" on the relevant <meta>'s, but this get "hairy" when you got many classes with components - it forces you to add the same <meta> tag to each and every part of the hbm file....and that is exactly the opposite on what inherit was intended for. meta inheritance was for reducing the need to duplicate the same information again and again.
My suggestion is to introduce a default-meta-inherit attribute on the <hibernate-mapping> tag. This flag would default to "true" (because that is the current default. If set to "false" then inheritance is disabled on <meta>, unless explicitly stated otherwise.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-23 21:28:25
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@hi...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-487 Summary: Unecessary object creation in CharBooleanType Type: Patch Status: Open Priority: Trivial Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Gavin King Reporter: Bertrand Renuart Created: Fri, 21 Nov 2003 1:51 PM Updated: Sun, 23 Nov 2003 3:27 PM Description: Unecessary objects are created when converting the data retrieved from the resultset to a Boolean. Original code: -------------- return new Boolean( code.toUpperCase().equals( getTrueString() ) ); Explanation: ------------ - code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead - new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used This would lead to the following code: if ( code.equalsIgnoreCase(getTrueString())) { return Boolean.TRUE; } else { return Boolean.FALSE; } A bit more efficient ;-) Note: what should we do if code != getFalseString()? Should we throw an SQLException ? --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-23 21:19:24
|
The following comment has been added to this issue:
Author: Bertrand Renuart
Created: Sun, 23 Nov 2003 3:18 PM
Body:
Thanks for having considered this case.
A few remarks though after you applied the patch:
- if you want CharBooleanType to throw an exception when it got something not TRUE nor FALSE, then the get() method on the ancestor should throw HibernateException as well (as nearly all other types do).
- below is what I propose for CharBooleanType.get():
public Object get(ResultSet rs, String name) throws HibernateException, SQLException {
String code = rs.getString(name);
if (code==null) return null;
if ( code.equalsIgnoreCase(getTrueString())) return Boolean.TRUE;
if( code.equalsIgnoreCase(getFalseString())) return Boolean.FALSE;
throw new HibernateException("Unable to convert '" + code + "' data to a Boolean");
}
- on the other hand, I think you made a mistake in your refactoring effort. For CharBooleanType.set(), you wrote:
st.setString( index, toString(value) );
where I believe it should be:
st.setString( index, toCharacter(value) );
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-487
Summary: Unecessary object creation in CharBooleanType
Type: Patch
Status: Open
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee: Max Rydahl Andersen
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 1:51 PM
Updated: Sun, 23 Nov 2003 3:18 PM
Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.
Original code:
--------------
return new Boolean( code.toUpperCase().equals( getTrueString() ) );
Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead
- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used
This would lead to the following code:
if ( code.equalsIgnoreCase(getTrueString())) {
return Boolean.TRUE;
}
else {
return Boolean.FALSE;
}
A bit more efficient ;-)
Note: what should we do if code != getFalseString()? Should we throw an SQLException ?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-23 21:01:24
|
The following issue has been updated:
Updater: Ara Abrahamian (mailto:ar...@ya...)
Date: Sun, 23 Nov 2003 3:00 PM
Changes:
Attachment changed to ReverseXMLDatabinder.java
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-493&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-493
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-493
Summary: ReverseXMLDatabinder and some improvments to XMLDatabinder
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Ara Abrahamian
Created: Sun, 23 Nov 2003 2:57 PM
Updated: Sun, 23 Nov 2003 3:00 PM
Environment: latest cvs code, 24 november
Description:
ReverseXMLDatabinder is attached to this issue. It reads xml file generated by hibernate's XMLDatabinder and replicates the objects.
Also I've added unbind() and unbindAll() methods to XMLDatabinder (can be pulled up to Databinder superclass). unbind excludes an object from xml export. So if you have a graph of objects and only some of them should be xmlized then unbind the unneeded ones.
Also notice that ReverseXMLDatabinder.fromXml() treats TimestampType and DateType specially due to incorrect pattern used by the formXml() method of these two types (it doesn't read in the same format toString writes the date). This code should be moved to TimestampType and DateType.
Ara.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-23 21:01:24
|
The following issue has been updated:
Updater: Ara Abrahamian (mailto:ar...@ya...)
Date: Sun, 23 Nov 2003 2:59 PM
Changes:
Attachment changed to XMLDatabinder.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-493&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-493
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-493
Summary: ReverseXMLDatabinder and some improvments to XMLDatabinder
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Ara Abrahamian
Created: Sun, 23 Nov 2003 2:57 PM
Updated: Sun, 23 Nov 2003 2:59 PM
Environment: latest cvs code, 24 november
Description:
ReverseXMLDatabinder is attached to this issue. It reads xml file generated by hibernate's XMLDatabinder and replicates the objects.
Also I've added unbind() and unbindAll() methods to XMLDatabinder (can be pulled up to Databinder superclass). unbind excludes an object from xml export. So if you have a graph of objects and only some of them should be xmlized then unbind the unneeded ones.
Also notice that ReverseXMLDatabinder.fromXml() treats TimestampType and DateType specially due to incorrect pattern used by the formXml() method of these two types (it doesn't read in the same format toString writes the date). This code should be moved to TimestampType and DateType.
Ara.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-23 20:59:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-493 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-493 Summary: ReverseXMLDatabinder and some improvments to XMLDatabinder Type: New Feature Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Reporter: Ara Abrahamian Created: Sun, 23 Nov 2003 2:57 PM Updated: Sun, 23 Nov 2003 2:57 PM Environment: latest cvs code, 24 november Description: ReverseXMLDatabinder is attached to this issue. It reads xml file generated by hibernate's XMLDatabinder and replicates the objects. Also I've added unbind() and unbindAll() methods to XMLDatabinder (can be pulled up to Databinder superclass). unbind excludes an object from xml export. So if you have a graph of objects and only some of them should be xmlized then unbind the unneeded ones. Also notice that ReverseXMLDatabinder.fromXml() treats TimestampType and DateType specially due to incorrect pattern used by the formXml() method of these two types (it doesn't read in the same format toString writes the date). This code should be moved to TimestampType and DateType. Ara. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-23 02:25:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-492 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-492 Summary: serialize mappings Type: New Feature Status: Unassigned Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Reporter: no_ejb Created: Sat, 22 Nov 2003 8:25 PM Updated: Sat, 22 Nov 2003 8:25 PM Environment: Any database Description: I have initiated a discussion about persist the mappings to avoid extra parsing each time starts up. Detail can be found at : http://forum.hibernate.org/viewtopic.php?t=925768&highlight= Here is the except: In my case, I have about 200 classes I am going to persist. The problem I am facing is that it takes about 1 minute for hibernate to parse all these .hbm.xml mappings (first phase and second phase) and my CPU pegged at 100%. Since my mappings rarely change, can I persist the mappings so the next time it just simple load the persisted version and bypass the first phase/second phase including xml validation etc? If in a rare chance, I do change my schema after the production I will let it reparse again of course. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-23 00:18:24
|
The following comment has been added to this issue:
Author: David D Phillips
Created: Sat, 22 Nov 2003 6:17 PM
Body:
I agree with you points 100%! I wasnt satisfied with JCS/OSCache and HashtableCache was just tooo simple. That's why i submitted this - however, after looking at EHCache, I was pleased, and now using EHCache instead!
Thanks...
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-475
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-475
Summary: A better memory cache
Type: New Feature
Status: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1
Assignee:
Reporter: David D Phillips
Created: Sun, 16 Nov 2003 5:50 PM
Updated: Sat, 22 Nov 2003 6:17 PM
Description:
A simple LRU memory cache backed on Java1.4 LinkedHashmap, with a maxSize & timeout configured via a properties file.
I have the CacheProvider and Cache (And testcases ofcourse) How do I attach them? Please contact dav...@ya... for them!
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-22 19:28:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-491 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-491 Summary: createSQLQuery should support joined-subclass Type: Improvement Status: Open Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 final Assignee: Max Rydahl Andersen Reporter: Max Rydahl Andersen Created: Sat, 22 Nov 2003 1:28 PM Updated: Sat, 22 Nov 2003 1:28 PM Description: select .... from persons {person}, customers {(Customer)person} where .... where Customer is a <joined-subclass> of Person. http://forum.hibernate.org/viewtopic.php?t=925439&highlight=createsqlquery+joined --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-22 17:25:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Sat, 22 Nov 2003 11:24 AM
Body:
hmm...this can not be automated easily.
I need to do a list of property/fields comparison between the two referenced classes to decide what property/fields is needed in the final class (since the component part and persistent part does not need to match).
I think i'll do this the simplest way and just add a <meta attribute="donotgenerate">true</meta> so you can control the generation ya'self. Any objections to that ?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-451
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-451
Summary: hbm2java is overwriting a class file with an empty one.
Type: Bug
Status: Open
Priority: Major
Project: Hibernate2
Versions:
2.1
Assignee: Max Rydahl Andersen
Reporter: Paul Callahan
Created: Mon, 3 Nov 2003 2:10 PM
Updated: Sat, 22 Nov 2003 11:24 AM
Environment: Red hat 9, amd pc
Description:
We're using hbm2java to create class files. When I set up a particular mapping, one of the class files gets overwritten.
Below, the file ValueObject.java that is created in the class mapping gets overwriten by a completely empty ValueObject.java. I'm assuming MapClass mapping is creating its own ValueObject.java.
<class name="KeyObject" table="ko">
<id name="id" type="string" unsaved-value="null" >
<column name="id" sql-type="char(32)" not-null="true"/>
<generator class="uuid.hex"/>
</id>
<property name="name" type="string" not-null="true"/>
<property name="someField" type="string" not-null="true"/>
</class>
<class name="ValueObject" table="vo">
<id name="id" type="string" unsaved-value="null" >
<column name="id" sql-type="char(32)" not-null="true"/>
<generator class="uuid.hex"/>
</id>
<property name="name" type="string" not-null="true"/>
<property name="someOtherField" type="string" not-null="true"/>
<map name="stuff" lazy="true" >
<key column="id"/>
<index column="key" type="string"/>
<element column="value" type="string"/>
</map>
</class>
<class name="MapClass" table="mc">
<id name="id" type="string" unsaved-value="null" >
<column name="id" sql-type="char(32)" not-null="true"/>
<generator class="uuid.hex"/>
</id>
<map name="kvMapping" lazy="true" >
<key column="id"/>
<composite-index class="KeyObject" >
<key-property name="name"/>
<key-property name="someField"/>
</composite-index>
<composite-element class="ValueObject" />
</map>
<property name="name" type="string" not-null="true"/>
<property name="someOtherField" type="string" not-null="true"/>
</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
|
|
From: <leg...@at...> - 2003-11-22 16:42:24
|
Message:
The following issue has been closed.
Resolver: Max Rydahl Andersen
Date: Sat, 22 Nov 2003 10:42 AM
Now fixed.
Made it a general fix so it works for all hql seperators and not just ")"'s.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-455
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-455
Summary: Substitution of named parameters in SQL query
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1 rc1
Versions:
2.1 beta 5
Assignee: Max Rydahl Andersen
Reporter: Alexey Kaigorodov
Created: Wed, 5 Nov 2003 2:46 AM
Updated: Sat, 22 Nov 2003 10:42 AM
Description:
The substring between colon and the following space is considered the name of parameter.
This incorrect in some cases e.g.
... (:bar=0 or foo=:bar) ...
For itself fix this in net.sf.hibernate.loader.SQLLoader
(attached)
--
With best regards,
Alex
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-22 14:37:04
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Sat, 22 Nov 2003 8:36 AM
Body:
So, ain't this one resolved ?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-487
Summary: Unecessary object creation in CharBooleanType
Type: Patch
Status: Open
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee: Max Rydahl Andersen
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 1:51 PM
Updated: Sat, 22 Nov 2003 8:36 AM
Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.
Original code:
--------------
return new Boolean( code.toUpperCase().equals( getTrueString() ) );
Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead
- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used
This would lead to the following code:
if ( code.equalsIgnoreCase(getTrueString())) {
return Boolean.TRUE;
}
else {
return Boolean.FALSE;
}
A bit more efficient ;-)
Note: what should we do if code != getFalseString()? Should we throw an SQLException ?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-22 12:19:05
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-489 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-489 Summary: Let the user specify wether inherit is default false or true Type: Improvement Status: Open Priority: Major Project: Hibernate2 Components: toolset Assignee: Max Rydahl Andersen Reporter: Max Rydahl Andersen Created: Sat, 22 Nov 2003 6:17 AM Updated: Sat, 22 Nov 2003 6:17 AM Description: "More and more people" reports that the default inherit strategy for <meta> sometimes conflict with their intentions. e.g. because all meta is inherited by default will meta="implements" in a class be applied to all nested <component> etc. The current workaround is to set inherit="false" on the relevant <meta>'s, but this get "hairy" when you got many classes with components - it forces you to add the same <meta> tag to each and every part of the hbm file....and that is exactly the opposite on what inherit was intended for. meta inheritance was for reducing the need to duplicate the same information again and again. My suggestion is to introduce a default-meta-inherit attribute on the <hibernate-mapping> tag. This flag would default to "true" (because that is the current default. If set to "false" then inheritance is disabled on <meta>, unless explicitly stated otherwise. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-22 12:13:05
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HBI-17 Here is an overview of the issue: --------------------------------------------------------------------- Key: HBI-17 Summary: Make getMetaAttributes() support meta-inheritance Type: Improvement Status: Open Priority: Major Project: Hibernate 1.2 Assignee: Max Rydahl Andersen Reporter: Max Rydahl Andersen Created: Sat, 22 Nov 2003 6:11 AM Updated: Sat, 22 Nov 2003 6:11 AM Description: Currentl getMetaAttributes() does not obey the inherit attribute on <meta> - it should. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-21 23:04:24
|
Message:
The following issue has been re-assigned.
Assignee: Max Rydahl Andersen (mailto:xa...@xa...)
Assigner: Gavin King (mailto:ga...@hi...)
Date: Fri, 21 Nov 2003 5:03 PM
Comment:
I applied the patch.
Yes, we should probably throw exception I suppose.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-487
Summary: Unecessary object creation in CharBooleanType
Type: Patch
Status: Open
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee: Max Rydahl Andersen
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 1:51 PM
Updated: Fri, 21 Nov 2003 5:03 PM
Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.
Original code:
--------------
return new Boolean( code.toUpperCase().equals( getTrueString() ) );
Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead
- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used
This would lead to the following code:
if ( code.equalsIgnoreCase(getTrueString())) {
return Boolean.TRUE;
}
else {
return Boolean.FALSE;
}
A bit more efficient ;-)
Note: what should we do if code != getFalseString()? Should we throw an SQLException ?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 22:25:25
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Fri, 21 Nov 2003 4:25 PM
OK, I've squashed the second exception.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-488
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-488
Summary: rollback fails on read-only cache
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1 rc1
Versions:
2.1 beta 6
Assignee: Gavin King
Reporter: Loren Rosen
Created: Fri, 21 Nov 2003 2:05 PM
Updated: Fri, 21 Nov 2003 4:25 PM
Environment: Mac OSX 10.1.5
JDK 1.3.1
Description:
I'm getting the message "AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate". Here's the situation:
I have a class with read-only caching (<cache usage="read-only"/>. But I do not have mutable="false" for this class-- perhaps that doesn't make sense, but I thought I should at least report the problem I stumbled on while trying to run this setup, before I change my configuration.
First, I create a new object (via new.... Session.save.... Transaction.commit). This does do the database insert (which perhaps it shouldn't do in this configuration).
Next, in a new session with a new transaction, I take the same object, and delete it (via Session.delete.... Transaction.commit). This gets an exception on the commit, "java.lang.UnsupportedOperationException: Can't write to a readonly object", which is reasonable.
Now the code goes to the exception handler, which naturally attempts to rollback the transaction. This raises another exception, with the "may indicate a bug message" :
[DEBUG] JDBCTransaction - -rollback
[ERROR] ReadOnlyCache - -Application attempted to edit read only item: 360449
[ERROR] AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate <java.lang.UnsupportedOperationException: Can't write to a readonly object>java.lang.UnsupportedOperationException: Can't write to a readonly object
at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47)
at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34)
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530)
at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90)
at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617)
at com.loren.DocumentExample.main(DocumentExample.java:71)
Exception in thread "main" net.sf.hibernate.AssertionFailure: Exception releasing cache locks
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:541)
at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90)
at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617)
at com.loren.DocumentExample.main(DocumentExample.java:71)
Caused by: java.lang.UnsupportedOperationException: Can't write to a readonly object
at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47)
at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34)
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530)
... 3 more
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 22:25:24
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@hi...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-488 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-488 Summary: rollback fails on read-only cache Type: Bug Status: Open Priority: Major Project: Hibernate2 Components: core Fix Fors: 2.1 rc1 Versions: 2.1 beta 6 Assignee: Gavin King Reporter: Loren Rosen Created: Fri, 21 Nov 2003 2:05 PM Updated: Fri, 21 Nov 2003 4:24 PM Environment: Mac OSX 10.1.5 JDK 1.3.1 Description: I'm getting the message "AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate". Here's the situation: I have a class with read-only caching (<cache usage="read-only"/>. But I do not have mutable="false" for this class-- perhaps that doesn't make sense, but I thought I should at least report the problem I stumbled on while trying to run this setup, before I change my configuration. First, I create a new object (via new.... Session.save.... Transaction.commit). This does do the database insert (which perhaps it shouldn't do in this configuration). Next, in a new session with a new transaction, I take the same object, and delete it (via Session.delete.... Transaction.commit). This gets an exception on the commit, "java.lang.UnsupportedOperationException: Can't write to a readonly object", which is reasonable. Now the code goes to the exception handler, which naturally attempts to rollback the transaction. This raises another exception, with the "may indicate a bug message" : [DEBUG] JDBCTransaction - -rollback [ERROR] ReadOnlyCache - -Application attempted to edit read only item: 360449 [ERROR] AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate <java.lang.UnsupportedOperationException: Can't write to a readonly object>java.lang.UnsupportedOperationException: Can't write to a readonly object at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47) at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34) at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530) at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90) at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617) at com.loren.DocumentExample.main(DocumentExample.java:71) Exception in thread "main" net.sf.hibernate.AssertionFailure: Exception releasing cache locks at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:541) at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90) at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617) at com.loren.DocumentExample.main(DocumentExample.java:71) Caused by: java.lang.UnsupportedOperationException: Can't write to a readonly object at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47) at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34) at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530) ... 3 more --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-21 22:19:24
|
Message: The following issue has been re-assigned. Assignee: Gavin King (mailto:ga...@hi...) --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-483 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-483 Summary: Odd behavior from query cache startup Type: Bug Status: Open Priority: Minor Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Gavin King Reporter: Loren Rosen Created: Thu, 20 Nov 2003 12:16 PM Updated: Fri, 21 Nov 2003 4:18 PM Environment: Mac OSX 10.1.5 JDK 1.3.1 Description: It seems that it takes 3 query calls before the query cache is propery initialized and starts caching queries. I'll grant this isn't so critical for overall effectiveness of the cache, but it will confuse someone who tries to write a very simple program to demonstrate the operation of the query cache. For example, if the gist of main() is this: Session sess; Long l = new Long(79); for (int i=1;i<=5;i++) { System.out.println("-----run query iteration " + i + " --------------"); sess = sessions.openSession(); runQuery(l, sess); sess.close(); } and here's the method it calls private static void runQuery(Long docId, Session sess) throws Exception { Document doc; Transaction tx = null; try { tx = sess.beginTransaction(); Query q = sess.createQuery("select from Document doc where doc.id=:docId"); q.setLong("docId", docId.longValue()); q.setCacheable(true); List list = q.list(); tx.commit(); } catch (Exception e) { tx.rollback(); throw e; } } If you run this with query logging enabled, you'll see that only the 4th and 5th iterations of loop succeed in getting the query results from the query cache. I've traced through the code, and I think I know what's going on. It's a bit complicated to explain, but I'll be happy to write it down if anyone wants to try fixing the problem. --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
|
From: <leg...@at...> - 2003-11-21 21:12:24
|
Message:
The following issue has been re-assigned.
Assignee: Gavin King (mailto:ga...@hi...)
Assigner: Max Rydahl Andersen (mailto:xa...@xa...)
Date: Fri, 21 Nov 2003 3:10 PM
Comment:
I'll throw this in Gavin's direction - he is the valid-data-guru ;)
(Gavin - should we throw exception on data that is neither TRUE nor FALSE ?...)
When decided then just throw the issue back to me and i'll commit it - unless you ain't that busy ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-487
Summary: Unecessary object creation in CharBooleanType
Type: Patch
Status: Open
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee: Gavin King
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 1:51 PM
Updated: Fri, 21 Nov 2003 3:10 PM
Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.
Original code:
--------------
return new Boolean( code.toUpperCase().equals( getTrueString() ) );
Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead
- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used
This would lead to the following code:
if ( code.equalsIgnoreCase(getTrueString())) {
return Boolean.TRUE;
}
else {
return Boolean.FALSE;
}
A bit more efficient ;-)
Note: what should we do if code != getFalseString()? Should we throw an SQLException ?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 20:30:24
|
The following issue has been updated:
Updater: Bertrand Renuart (mailto:ber...@mo...)
Date: Fri, 21 Nov 2003 2:29 PM
Comment:
Hmmm... fair enough, but the 'stringToObject' method already complains if it receives something that doesn't map to true or false.
Anyway, I believe Hibernate should complain when getting something unexpected from the database - don't you think so ?
When walking the class hierarchy, I notice the NullableType (ancestor) declares to throw SQLException AND HibernateException. The HibernateException has been dropped below in the hierarchy.
I propose to reintroduce it so CharBooleanType can throw an HibernateException when it receives invalid data. The attachment (hibernate-HB487-patch-v2.txt) is a new version of the patch containing this change.
Moreover, I made the same optimization as described above to BooleanType.
Feel free to comment and/or reject my changes ;-)
Changes:
Attachment changed to hibernate-HB487-patch-v2.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-487
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-487
Summary: Unecessary object creation in CharBooleanType
Type: Patch
Status: Unassigned
Priority: Trivial
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 1:51 PM
Updated: Fri, 21 Nov 2003 2:29 PM
Description:
Unecessary objects are created when converting the data retrieved from the resultset to a Boolean.
Original code:
--------------
return new Boolean( code.toUpperCase().equals( getTrueString() ) );
Explanation:
------------
- code.toUpperCase() creates a new String - code.equalsIgnoreCase() should be used instead
- new Boolean() creates a new Boolean instance where Boolean.TRUE | FALSE could be used
This would lead to the following code:
if ( code.equalsIgnoreCase(getTrueString())) {
return Boolean.TRUE;
}
else {
return Boolean.FALSE;
}
A bit more efficient ;-)
Note: what should we do if code != getFalseString()? Should we throw an SQLException ?
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 20:11:24
|
The following comment has been added to this issue:
Author: Loren Rosen
Created: Fri, 21 Nov 2003 2:10 PM
Body:
In fairness, I should note that hibernate does warn about this situation:
[WARN] Binder - -read-only cache configured for mutable: com.loren.Document
so if you take the point of view that "all bets are off" once this warning is given, then this is an "expected" bug that doesn't have to fixed.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-488
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-488
Summary: rollback fails on read-only cache
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Loren Rosen
Created: Fri, 21 Nov 2003 2:05 PM
Updated: Fri, 21 Nov 2003 2:10 PM
Environment: Mac OSX 10.1.5
JDK 1.3.1
Description:
I'm getting the message "AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate". Here's the situation:
I have a class with read-only caching (<cache usage="read-only"/>. But I do not have mutable="false" for this class-- perhaps that doesn't make sense, but I thought I should at least report the problem I stumbled on while trying to run this setup, before I change my configuration.
First, I create a new object (via new.... Session.save.... Transaction.commit). This does do the database insert (which perhaps it shouldn't do in this configuration).
Next, in a new session with a new transaction, I take the same object, and delete it (via Session.delete.... Transaction.commit). This gets an exception on the commit, "java.lang.UnsupportedOperationException: Can't write to a readonly object", which is reasonable.
Now the code goes to the exception handler, which naturally attempts to rollback the transaction. This raises another exception, with the "may indicate a bug message" :
[DEBUG] JDBCTransaction - -rollback
[ERROR] ReadOnlyCache - -Application attempted to edit read only item: 360449
[ERROR] AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate <java.lang.UnsupportedOperationException: Can't write to a readonly object>java.lang.UnsupportedOperationException: Can't write to a readonly object
at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47)
at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34)
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530)
at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90)
at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617)
at com.loren.DocumentExample.main(DocumentExample.java:71)
Exception in thread "main" net.sf.hibernate.AssertionFailure: Exception releasing cache locks
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:541)
at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90)
at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617)
at com.loren.DocumentExample.main(DocumentExample.java:71)
Caused by: java.lang.UnsupportedOperationException: Can't write to a readonly object
at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47)
at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34)
at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530)
... 3 more
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 20:06:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-488 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-488 Summary: rollback fails on read-only cache Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Reporter: Loren Rosen Created: Fri, 21 Nov 2003 2:05 PM Updated: Fri, 21 Nov 2003 2:05 PM Environment: Mac OSX 10.1.5 JDK 1.3.1 Description: I'm getting the message "AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate". Here's the situation: I have a class with read-only caching (<cache usage="read-only"/>. But I do not have mutable="false" for this class-- perhaps that doesn't make sense, but I thought I should at least report the problem I stumbled on while trying to run this setup, before I change my configuration. First, I create a new object (via new.... Session.save.... Transaction.commit). This does do the database insert (which perhaps it shouldn't do in this configuration). Next, in a new session with a new transaction, I take the same object, and delete it (via Session.delete.... Transaction.commit). This gets an exception on the commit, "java.lang.UnsupportedOperationException: Can't write to a readonly object", which is reasonable. Now the code goes to the exception handler, which naturally attempts to rollback the transaction. This raises another exception, with the "may indicate a bug message" : [DEBUG] JDBCTransaction - -rollback [ERROR] ReadOnlyCache - -Application attempted to edit read only item: 360449 [ERROR] AssertionFailure - -An AssertionFailure occured - this may indicate a bug in Hibernate <java.lang.UnsupportedOperationException: Can't write to a readonly object>java.lang.UnsupportedOperationException: Can't write to a readonly object at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47) at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34) at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530) at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90) at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617) at com.loren.DocumentExample.main(DocumentExample.java:71) Exception in thread "main" net.sf.hibernate.AssertionFailure: Exception releasing cache locks at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:541) at net.sf.hibernate.transaction.JDBCTransaction.rollback(JDBCTransaction.java:90) at com.loren.DocumentExample.deleteTestDoc(DocumentExample.java:617) at com.loren.DocumentExample.main(DocumentExample.java:71) Caused by: java.lang.UnsupportedOperationException: Can't write to a readonly object at net.sf.hibernate.cache.ReadOnlyCache.release(ReadOnlyCache.java:47) at net.sf.hibernate.impl.ScheduledDeletion.afterTransactionCompletion(ScheduledDeletion.java:34) at net.sf.hibernate.impl.SessionImpl.afterTransactionCompletion(SessionImpl.java:530) ... 3 more --------------------------------------------------------------------- JIRA INFORMATION: This message is automatically generated by JIRA. If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira |
93 messages has been excluded from this view by a project administrator.
