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-21 20:01:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 21 Nov 2003 2:00 PM
Body:
Normally the definition on True is everything else but true.
So - no need for throwing exceptions ;)
---------------------------------------------------------------------
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:00 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 19:57:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 21 Nov 2003 1:56 PM
Body:
hmm....the following is from the ResultSet JavaDoc:
"Columns are numbered from 1. For maximum portability, result set columns within each row should be read in left-to-right order, and each column should be read only once."
So, insanly stupid driver implementations could refrain from supporting accessing this data twice - sick!
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-484
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-484
Summary: ResultSet can not re-read row data for column 2
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Benoit Menendez
Created: Thu, 20 Nov 2003 12:24 PM
Updated: Fri, 21 Nov 2003 1:56 PM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 19:55:24
|
The following issue has been updated:
Updater: Bertrand Renuart (mailto:ber...@mo...)
Date: Fri, 21 Nov 2003 1:53 PM
Comment:
This patch contains the proposed modifications.
Changes:
Attachment changed to hibernate-HB487-patch.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 1:53 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 19:51:27
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- 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 1:51 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 19:48:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 21 Nov 2003 1:47 PM
Body:
If you can find the line in the JDBC spec that says a column may only be read in order - then please point me to it !? For me this looks like a faulty driver!
Text from related sites about the issue:
"
2) Using JDBC-ODBC into SQL Server, I cannot access the
ResultSet fields out of order. Will this be corrected?
...
when i posted this to JSP-Interest, they said that the fact you
can't access results out of order is a well-known bug. I asked
a sun engineer if they would correct that with JDBC 3, and he
said it was a problem with ODBC, not JDBC."
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-484
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-484
Summary: ResultSet can not re-read row data for column 2
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Benoit Menendez
Created: Thu, 20 Nov 2003 12:24 PM
Updated: Fri, 21 Nov 2003 1:47 PM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 18:44:25
|
The following comment has been added to this issue:
Author: Benoit Menendez
Created: Fri, 21 Nov 2003 12:44 PM
Body:
I have added a ResultSet proxy which buffers the column values and it now works, so this is definitely an issue with reading columns out of sequence.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-484
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-484
Summary: ResultSet can not re-read row data for column 2
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Benoit Menendez
Created: Thu, 20 Nov 2003 12:24 PM
Updated: Fri, 21 Nov 2003 12:44 PM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 17:40:24
|
The following issue has been updated:
Updater: Loren Rosen (mailto:lor...@ma...)
Date: Fri, 21 Nov 2003 11:39 AM
Comment:
annotated debug log file
Changes:
Attachment changed to a.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-483&page=history
---------------------------------------------------------------------
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: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Loren Rosen
Created: Thu, 20 Nov 2003 12:16 PM
Updated: Fri, 21 Nov 2003 11:39 AM
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 17:38:27
|
The following comment has been added to this issue:
Author: Loren Rosen
Created: Fri, 21 Nov 2003 11:38 AM
Body:
The little test program here uses an existing database; it doesn't insert or modify anything.
I'll attach a debug log. Note that I added some additional debug logging statements to the hibernate code, whose meaning I hope is self-explanatory. Also, I've manually added some comments to the log file, prefixed by "****", which indicate what I think is going on. Basically, the first time through hibernates caches the query, but doesn't set the update timestamp. The next time the update timestamp gets set, and the query is re-cached. The query cache timestamp is before the update timestamp, and consequently, the third time through, hibernate decides the query is not up to date. The query gets cached yet again, this time with a later timestamp, and so the fourth time through it succeeds in getting using the cached query.
---------------------------------------------------------------------
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: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Loren Rosen
Created: Thu, 20 Nov 2003 12:16 PM
Updated: Fri, 21 Nov 2003 11:38 AM
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 16:10:24
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Fri, 21 Nov 2003 10:09 AM
Thanks, I applied this patch
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-486
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-486
Summary: String padded with \0 when using type="text"
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Components:
core
Fix Fors:
2.1 rc1
Versions:
2.1 beta 6
Assignee:
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 8:27 AM
Updated: Fri, 21 Nov 2003 10:09 AM
Description:
Hibernate returns string padded with trailing \0 when mapped using type TEXT:
<property name="name" type="text">
Problem is located in net.sf.hibernate.type.TextType - buffer used to read data is added to the string under construction without taking care of the amount of data read.
---------------------------------------------------------------------
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 15:29:24
|
The following comment has been added to this issue:
Author: Richard Scranton
Created: Fri, 21 Nov 2003 9:29 AM
Body:
Hibernate is generating code that behaves differently depending on whether you allow Sybase (via the connection property DYNAMIC_PREPARE) to precompile prepared statements at the server.
If you insert into a table having an identity column, the value of the recently added identity is available as @@identity. If Hibernate generates a string of SQL statements like this:
insert ...
select @identity
as distinct prepared statements, "select @@identity" will not return the expected value if the connection property DYNAMIC_PREPARE=true, because on the server side, the insert statement becomes a dynamically-generated stored procedure, and the value of the recently added identity is not available outside the stored procedure that produced the insert. Leaving DYNAMIC_PREPARE=false gives the expected behavior, but gives performance no better than sending unprepared strings of SQL text to the server.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-485
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-485
Summary: DYNAMIC_PREPARE and @@identity
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Assignee:
Reporter: Richard Scranton
Created: Thu, 20 Nov 2003 1:22 PM
Updated: Fri, 21 Nov 2003 9:29 AM
Description:
Using the Sybase jConnect jdbc driver version 4.5 or 5.5, if the connection property DYNAMIC_PREPARE is set to "true", "select @@identity" will always return a "0". This is an artifact of the Sybase implementation of prepared statements. Statements compiled at the server become stored procedures marked by the "DYN" token, and appear named as dyn100, dyn101, etc in the
captured TDS stream. The value of @@identity is lost at the end of a procedure, so a sequence of prepared statements like:
insert into Yadda (val1,val2) values ( 1,2 )
select @@identity
will execute as expected when DYNAMIC_PREPARE is false. If it is set to true, the statement "select @@identity" will return "0". Sybase suggests something like this workaround to get the expected behavior:
String nl=System.getProperty("line.separator");
PreparedStaement ps=conn.prepareStatement(
"insert into Yadd (val1,val2) values ( 1,2 )"
+ nl
+ "select @@identity");
Leaving DYNAMIC_PREPARE set false gives away throughput if the queries being sent and parsed are of significant size. TDS dumps show they are being sent and parsed with each invocation. Setting DYNAMIC_PREPARE to true allows reuse of the parsed queries.
---------------------------------------------------------------------
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 14:31:24
|
The following issue has been updated:
Updater: Bertrand Renuart (mailto:ber...@mo...)
Date: Fri, 21 Nov 2003 8:30 AM
Comment:
The attachment is a patch for Hibernate 2.1-B6 fixing the problem.
In addition, byte-to-char convertion has been modified to be compliant with latest JDK versions (replacing deprecated methods).
Changes:
Attachment changed to hibernate-HB486-patch.txt
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-486&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-486
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-486
Summary: String padded with \0 when using type="text"
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Bertrand Renuart
Created: Fri, 21 Nov 2003 8:27 AM
Updated: Fri, 21 Nov 2003 8:30 AM
Description:
Hibernate returns string padded with trailing \0 when mapped using type TEXT:
<property name="name" type="text">
Problem is located in net.sf.hibernate.type.TextType - buffer used to read data is added to the string under construction without taking care of the amount of data read.
---------------------------------------------------------------------
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 14:27:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-486 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-486 Summary: String padded with \0 when using type="text" Type: Bug Status: Unassigned Priority: Major Project: Hibernate2 Components: core Versions: 2.1 beta 6 Assignee: Reporter: Bertrand Renuart Created: Fri, 21 Nov 2003 8:27 AM Updated: Fri, 21 Nov 2003 8:27 AM Description: Hibernate returns string padded with trailing \0 when mapped using type TEXT: <property name="name" type="text"> Problem is located in net.sf.hibernate.type.TextType - buffer used to read data is added to the string under construction without taking care of the amount of data read. --------------------------------------------------------------------- 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 10:44:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Fri, 21 Nov 2003 4:44 AM
Body:
We have HashtableCacheProvider for that...
---------------------------------------------------------------------
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: Fri, 21 Nov 2003 4:44 AM
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-21 10:42:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Fri, 21 Nov 2003 4:41 AM
Body:
For testing and simplicity ?
Maybe even an example for other cacheproviders ?
Just thought ;)
---------------------------------------------------------------------
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: Fri, 21 Nov 2003 4:41 AM
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-21 10:21:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Fri, 21 Nov 2003 4:20 AM
Body:
Well, we already have EHCache and OSCache - is there any good reason why we need also this?
---------------------------------------------------------------------
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: Fri, 21 Nov 2003 4:20 AM
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: Damian M. <da...@sp...> - 2003-11-21 09:26:31
|
We have a webapplication and recently had the following exception : net.sf.hibernate.HibernateException: Found shared references to a collection at net.sf.hibernate.impl.SessionImpl.updateReachableCollection(SessionImpl.java:2794) at net.sf.hibernate.impl.SessionImpl.updateReachable(SessionImpl.java:2830) at net.sf.hibernate.impl.SessionImpl.updateReachables(SessionImpl.java:2935) at net.sf.hibernate.impl.SessionImpl.flushEntity(SessionImpl.java:2479) at net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2345) at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2223) at net.sf.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1763) at net.sf.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1464) at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1424) at net.sf.hibernate.impl.QueryImpl.list(QueryImpl.java:43) In the application we are getting the same instance of on abject from a JSP an then from servlet in diffrent HTTP Requests. The Hibernate Session we are using is the same in the two requests. What is the cause for this? How can we solve it? |
|
From: <leg...@at...> - 2003-11-21 08:43:25
|
The following comment has been added to this issue:
Author: Alexey Kaigorodov
Created: Fri, 21 Nov 2003 2:43 AM
Body:
No, attachments is correct.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-440
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-440
Summary: Direct collection property access
Type: Bug
Status: Closed
Priority: Major
Resolution: CANNOT REPRODUCE
Project: Hibernate2
Components:
core
Fix Fors:
2.1 rc1
Versions:
2.1 beta 5
Assignee: Max Rydahl Andersen
Reporter: Alexey Kaigorodov
Created: Fri, 31 Oct 2003 3:26 AM
Updated: Fri, 21 Nov 2003 2:43 AM
Description:
<bag name="..." access="field">
...
</bag>
causes exception unless exists getter
net.sf.hibernate.MappingException: Problem trying to set property type by reflection
at net.sf.hibernate.mapping.Value.setTypeByReflection(Value.java:103)
at net.sf.hibernate.cfg.Binder.createProperty(Binder.java:953)
at net.sf.hibernate.cfg.Binder.propertiesFromXML(Binder.java:946)
at net.sf.hibernate.cfg.Binder.bindRootClass(Binder.java:313)
at net.sf.hibernate.cfg.Binder.bindRoot(Binder.java:1143)
at net.sf.hibernate.cfg.Configuration.add(Configuration.java:243)
at net.sf.hibernate.cfg.Configuration.addInputStream(Configuration.java:266)
at net.sf.hibernate.cfg.Configuration.addJar(Configuration.java:349)
at net.sf.hibernate.cfg.Configuration.addJar(Configuration.java:320)
...
Caused by: net.sf.hibernate.PropertyNotFoundException: Could not find a getter for ... in class ...
--
With best regards,
Alexey
---------------------------------------------------------------------
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 04:21:24
|
The following comment has been added to this issue:
Author: Jason Polites
Created: Thu, 20 Nov 2003 10:20 PM
Body:
Thanks all. I was getting a SELECT FOR UPDATE error on SQL Server 2000 when trying to generate an identity key. This fixed it for me.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-437
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-437
Summary: Add Dialect for Microsoft SQL Server
Type: Improvement
Status: Open
Priority: Major
Project: Hibernate2
Components:
core
Versions:
2.1 beta 4
Assignee: Gavin King
Reporter: John Kristian
Created: Thu, 30 Oct 2003 1:20 PM
Updated: Thu, 20 Nov 2003 10:20 PM
Environment: Microsoft SQL Server
Description:
Please enable Hibernate to work with Microsoft SQL Server, using Transact-SQL statements of the form "INSERT ... SELECT SCOPE_IDENTITY()" to insert a row whose identifier is generated by the database.
The patch mssql.zip (attached) works for me. If you like, I'll gladly make additional changes to clean up the indentation and exception handling. <mailto:jkr...@do...>
A related forum thread is http://forum.hibernate.org/viewtopic.php?p=2176297
---------------------------------------------------------------------
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 03:53:24
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Thu, 20 Nov 2003 9:52 PM
OK, i only fixed half the problem last time. Its fixed now.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-479
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-479
Summary: Session.replicate() does not preserve object associations
Type: Bug
Status: Closed
Priority: Major
Resolution: FIXED
Project: Hibernate2
Fix Fors:
2.1 rc1
Versions:
2.1
Assignee:
Reporter: Brian Denny
Created: Tue, 18 Nov 2003 11:56 AM
Updated: Thu, 20 Nov 2003 9:52 PM
Description:
Calling session.replicate() on a parent object with a many-to-many-mapped List of children fails to replicate the association, i.e., no rows are created in the association table, although all the objects themselves are inserted.
In order to see this bug, the objects you are trying to replicate() must have been actually load()ed from some other session; i.e., if you instantiate some objects freshly and assign ids to them and call session.replicate(), you don't see the bug.
I have created a little project with an Ant build script which demonstrates this bug. You may download it from
http://www.briandenny.net/hibernate_bug.tgz
---------------------------------------------------------------------
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 02:05:24
|
The following comment has been added to this issue:
Author: Benoit Menendez
Created: Thu, 20 Nov 2003 8:05 PM
Body:
It appears from tracing the problem that Hibernate reads the columns out of order, for example reading the first column, the second, the third then the second column again which is not supported by this particular driver.
The SQL is perfectly fine, but Hibernate ends up reading the DOCUMENT_ID (second) column again after having read the entire record.
Again this is speculation.
This is the latest Microsoft SQL driver and look very good otherwise and only this particular construct I am using with file documents and versions (see file) causes this problem to occur.
I am building a proxy for ResultSet that will work around this problem (and Blob issues as well)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-484
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-484
Summary: ResultSet can not re-read row data for column 2
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Benoit Menendez
Created: Thu, 20 Nov 2003 12:24 PM
Updated: Thu, 20 Nov 2003 8:05 PM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2003-11-21 01:54:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 20 Nov 2003 7:53 PM
Body:
This would not be unexpected if you just created the rows before running the queries. Hibernate uses a timstamping scheme to try and ensure cache consistency.
Do you have a Hiberanate debug log?
---------------------------------------------------------------------
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: Unassigned
Priority: Minor
Project: Hibernate2
Components:
core
Versions:
2.1 beta 6
Assignee:
Reporter: Loren Rosen
Created: Thu, 20 Nov 2003 12:16 PM
Updated: Thu, 20 Nov 2003 7:53 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 01:50:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 20 Nov 2003 7:48 PM
Body:
Are you certain that you are not calling Hibernate.initialize() on a collection that belongs to a disconnected session?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-482
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-482
Summary: NPE in net.sf.hibernate.impl.SessionImpl
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 4
Assignee:
Reporter: Michail Jekimov
Created: Thu, 20 Nov 2003 8:50 AM
Updated: Thu, 20 Nov 2003 7:48 PM
Environment: WinXP Professional, JDK 1.4, Tomcat 4.1.24
Description:
I get a NPE in the following method in
if (!ce.initialized)
It happens sporadically but rather often.
/**
* called by a collection that wants to initialize itself
*/
public void initialize(PersistentCollection collection, boolean writing) throws HibernateException {
CollectionEntry ce = getCollectionEntry(collection);
if ( !ce.initialized ) {
if ( log.isTraceEnabled() ) log.trace( "initializing collection " + MessageHelper.infoString(ce.loadedPersister, ce.loadedKey) );
try {
ce.loadedPersister.getInitializer().initialize(ce.loadedKey, this);
}
catch (SQLException sqle) {
throw new JDBCException("SQLException initializing collection", sqle);
}
}
}
---------------------------------------------------------------------
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 01:46:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 20 Nov 2003 7:45 PM
Body:
P.S. you should not be using beta4 since beta6 is now available with many bugfixes.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-482
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-482
Summary: NPE in net.sf.hibernate.impl.SessionImpl
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 4
Assignee:
Reporter: Michail Jekimov
Created: Thu, 20 Nov 2003 8:50 AM
Updated: Thu, 20 Nov 2003 7:45 PM
Environment: WinXP Professional, JDK 1.4, Tomcat 4.1.24
Description:
I get a NPE in the following method in
if (!ce.initialized)
It happens sporadically but rather often.
/**
* called by a collection that wants to initialize itself
*/
public void initialize(PersistentCollection collection, boolean writing) throws HibernateException {
CollectionEntry ce = getCollectionEntry(collection);
if ( !ce.initialized ) {
if ( log.isTraceEnabled() ) log.trace( "initializing collection " + MessageHelper.infoString(ce.loadedPersister, ce.loadedKey) );
try {
ce.loadedPersister.getInitializer().initialize(ce.loadedKey, this);
}
catch (SQLException sqle) {
throw new JDBCException("SQLException initializing collection", sqle);
}
}
}
---------------------------------------------------------------------
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 01:44:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 20 Nov 2003 7:44 PM
Body:
I mean - this is absolutely useless to me. The one thing I *do* have already is the Hibernate source. What I don't have is your code. Please submit a very simple main() method that reproduces the problem.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-482
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-482
Summary: NPE in net.sf.hibernate.impl.SessionImpl
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Versions:
2.1 beta 4
Assignee:
Reporter: Michail Jekimov
Created: Thu, 20 Nov 2003 8:50 AM
Updated: Thu, 20 Nov 2003 7:44 PM
Environment: WinXP Professional, JDK 1.4, Tomcat 4.1.24
Description:
I get a NPE in the following method in
if (!ce.initialized)
It happens sporadically but rather often.
/**
* called by a collection that wants to initialize itself
*/
public void initialize(PersistentCollection collection, boolean writing) throws HibernateException {
CollectionEntry ce = getCollectionEntry(collection);
if ( !ce.initialized ) {
if ( log.isTraceEnabled() ) log.trace( "initializing collection " + MessageHelper.infoString(ce.loadedPersister, ce.loadedKey) );
try {
ce.loadedPersister.getInitializer().initialize(ce.loadedKey, this);
}
catch (SQLException sqle) {
throw new JDBCException("SQLException initializing collection", sqle);
}
}
}
---------------------------------------------------------------------
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 01:42:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Thu, 20 Nov 2003 7:41 PM
Body:
Ummmmm .... what exactly is the problem here? You are using a buggy driver?
The generated SQL is correct, right?
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-484
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-484
Summary: ResultSet can not re-read row data for column 2
Type: Bug
Status: Unassigned
Priority: Major
Project: Hibernate2
Assignee:
Reporter: Benoit Menendez
Created: Thu, 20 Nov 2003 12:24 PM
Updated: Thu, 20 Nov 2003 7:41 PM
Description:
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
93 messages has been excluded from this view by a project administrator.
