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...> - 2004-01-11 17:11:25
|
The following issue has been updated:
Updater: Michael Gloegl (mailto:gl...@ok...)
Date: Sun, 11 Jan 2004 11:10 AM
Changes:
Attachment changed to hbm2java_validate.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-617&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-617
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-617
Summary: let hbm2java validate mappings - Includes Patch
Type: Improvement
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Assignee:
Reporter: Michael Gloegl
Created: Sun, 11 Jan 2004 11:03 AM
Updated: Sun, 11 Jan 2004 11:10 AM
Environment: Hiberante 2.1.1
Description:
This is a simple patch to let hbm2java validate the XML file before generating the mapping. This might help to prevent error reports when the Mapping is incorrect.
---------------------------------------------------------------------
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...> - 2004-01-11 17:04:25
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-617 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-617 Summary: let hbm2java validate mappings - Includes Patch Type: Improvement Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: toolset Assignee: Reporter: Michael Gloegl Created: Sun, 11 Jan 2004 11:03 AM Updated: Sun, 11 Jan 2004 11:03 AM Environment: Hiberante 2.1.1 Description: This is a simple patch to let hbm2java validate the XML file before generating the mapping. This might help to prevent error reports when the Mapping is incorrect. --------------------------------------------------------------------- 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...> - 2004-01-11 02:41:27
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 8:41 PM
Thanks I applied this patch.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-615
Summary: Make SchemaExport use "IF EXISTS" for generators - Includes Patch
Type: Improvement
Status: Closed
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1.1
Assignee:
Reporter: Michael Gloegl
Created: Sat, 10 Jan 2004 10:20 AM
Updated: Sat, 10 Jan 2004 8:41 PM
Environment: Hibernate 2.1.1
Description:
When droping tables for HiLo and other TableGenerators, the IF EXISTS syntax should be used if the Dialect supports it.
---------------------------------------------------------------------
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...> - 2004-01-11 02:27:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 10 Jan 2004 8:25 PM
Body:
In fact, looking again, you have a VERY strange mapping, where you represent a one-to-one association as two many-to-ones, using two foreign key constraints. I don't think this is a good thing. HIbernate has built in features to do all this stuff you don't need to do "funny" things.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-616
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-616
Summary: Cascading deletion problem with 2.1.1
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Versions:
2.1.1
Assignee:
Reporter: Peter Fassev
Created: Sat, 10 Jan 2004 4:50 PM
Updated: Sat, 10 Jan 2004 8:25 PM
Environment: Windows 2000, MS SQL-Server
Description:
The problem I am trying to explain does not happen with 2.0.3 and all previous versions of Hibernate and I am not quite sure if the behavior under 2.1.1 has been explicitly changed.
There are two classes with a single property, say A (the father) and B (the child), where A.child = B and B.father = A.
Each of the classes implements Lifecycle and has the onDelete() method, the method of class A look like:
public boolean onDelete(Session s) throws CallbackException {
if (this.child != null) {
B child = this.child;
setNewChild(null);
try {
s.delete(child);
} catch (HibernateException e) {
throw new CallbackException(e);
}
}
return NO_VETO;
}
which deletes the child of type B also.
However, when I try to delete an instance of A, there is an SQL Exception, thrown from the database, with a message, that a foreign key constraint has been violated.
I tested the program with Hibernate 2.0.3 and it works fine. The log-file shows, that Hibernate 2.0.3 first saves the changed state of B and A and after that deletes the different instances, so there are no foreign key violation. In a contrary, 2.1.1 does not update the database state of the changed objects and directly tries to delete them. This causes the exception.
I know, I can simply set cascade="all", or set the database option to cascade the deletions, but my question is, is this a bug, or simply a new behavior, which is introduced with 2.1.1?
---------------------------------------------------------------------
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...> - 2004-01-11 02:03:24
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 10 Jan 2004 8:03 PM
Body:
The behavior of onDelete() was changed in 2.1 and there was, indeed, the potential to break some existing code.
Note that it is not normal to cascade deletion in the same direction as a foreign key constraint. It is normal to cascade deletion _to_ rows that own a foreign key of the row being deleted. So your usecase is a bit strange, I think.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-616
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-616
Summary: Cascading deletion problem with 2.1.1
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Versions:
2.1.1
Assignee:
Reporter: Peter Fassev
Created: Sat, 10 Jan 2004 4:50 PM
Updated: Sat, 10 Jan 2004 8:03 PM
Environment: Windows 2000, MS SQL-Server
Description:
The problem I am trying to explain does not happen with 2.0.3 and all previous versions of Hibernate and I am not quite sure if the behavior under 2.1.1 has been explicitly changed.
There are two classes with a single property, say A (the father) and B (the child), where A.child = B and B.father = A.
Each of the classes implements Lifecycle and has the onDelete() method, the method of class A look like:
public boolean onDelete(Session s) throws CallbackException {
if (this.child != null) {
B child = this.child;
setNewChild(null);
try {
s.delete(child);
} catch (HibernateException e) {
throw new CallbackException(e);
}
}
return NO_VETO;
}
which deletes the child of type B also.
However, when I try to delete an instance of A, there is an SQL Exception, thrown from the database, with a message, that a foreign key constraint has been violated.
I tested the program with Hibernate 2.0.3 and it works fine. The log-file shows, that Hibernate 2.0.3 first saves the changed state of B and A and after that deletes the different instances, so there are no foreign key violation. In a contrary, 2.1.1 does not update the database state of the changed objects and directly tries to delete them. This causes the exception.
I know, I can simply set cascade="all", or set the database option to cascade the deletions, but my question is, is this a bug, or simply a new behavior, which is introduced with 2.1.1?
---------------------------------------------------------------------
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...> - 2004-01-10 22:53:24
|
The following issue has been updated:
Updater: Peter Fassev (mailto:fa...@gm...)
Date: Sat, 10 Jan 2004 4:51 PM
Comment:
I am adding a simle test program.
Changes:
Attachment changed to delete_test.zip
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-616&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-616
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-616
Summary: Cascading deletion problem with 2.1.1
Type: Bug
Status: Unassigned
Priority: Major
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Versions:
2.1.1
Assignee:
Reporter: Peter Fassev
Created: Sat, 10 Jan 2004 4:50 PM
Updated: Sat, 10 Jan 2004 4:51 PM
Environment: Windows 2000, MS SQL-Server
Description:
The problem I am trying to explain does not happen with 2.0.3 and all previous versions of Hibernate and I am not quite sure if the behavior under 2.1.1 has been explicitly changed.
There are two classes with a single property, say A (the father) and B (the child), where A.child = B and B.father = A.
Each of the classes implements Lifecycle and has the onDelete() method, the method of class A look like:
public boolean onDelete(Session s) throws CallbackException {
if (this.child != null) {
B child = this.child;
setNewChild(null);
try {
s.delete(child);
} catch (HibernateException e) {
throw new CallbackException(e);
}
}
return NO_VETO;
}
which deletes the child of type B also.
However, when I try to delete an instance of A, there is an SQL Exception, thrown from the database, with a message, that a foreign key constraint has been violated.
I tested the program with Hibernate 2.0.3 and it works fine. The log-file shows, that Hibernate 2.0.3 first saves the changed state of B and A and after that deletes the different instances, so there are no foreign key violation. In a contrary, 2.1.1 does not update the database state of the changed objects and directly tries to delete them. This causes the exception.
I know, I can simply set cascade="all", or set the database option to cascade the deletions, but my question is, is this a bug, or simply a new behavior, which is introduced with 2.1.1?
---------------------------------------------------------------------
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...> - 2004-01-10 22:51:24
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-616 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-616 Summary: Cascading deletion problem with 2.1.1 Type: Bug Status: Unassigned Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: core Versions: 2.1.1 Assignee: Reporter: Peter Fassev Created: Sat, 10 Jan 2004 4:50 PM Updated: Sat, 10 Jan 2004 4:50 PM Environment: Windows 2000, MS SQL-Server Description: The problem I am trying to explain does not happen with 2.0.3 and all previous versions of Hibernate and I am not quite sure if the behavior under 2.1.1 has been explicitly changed. There are two classes with a single property, say A (the father) and B (the child), where A.child = B and B.father = A. Each of the classes implements Lifecycle and has the onDelete() method, the method of class A look like: public boolean onDelete(Session s) throws CallbackException { if (this.child != null) { B child = this.child; setNewChild(null); try { s.delete(child); } catch (HibernateException e) { throw new CallbackException(e); } } return NO_VETO; } which deletes the child of type B also. However, when I try to delete an instance of A, there is an SQL Exception, thrown from the database, with a message, that a foreign key constraint has been violated. I tested the program with Hibernate 2.0.3 and it works fine. The log-file shows, that Hibernate 2.0.3 first saves the changed state of B and A and after that deletes the different instances, so there are no foreign key violation. In a contrary, 2.1.1 does not update the database state of the changed objects and directly tries to delete them. This causes the exception. I know, I can simply set cascade="all", or set the database option to cascade the deletions, but my question is, is this a bug, or simply a new behavior, which is introduced with 2.1.1? --------------------------------------------------------------------- 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...> - 2004-01-10 21:57:25
|
The following comment has been added to this issue:
Author: Jan Riis
Created: Sat, 10 Jan 2004 3:56 PM
Body:
YES! ... that's it, thanks Gavin
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-612
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-612
Summary: SchemaExport: DB2 CLOB fails
Type: Bug
Status: Closed
Priority: Blocker
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1
Assignee:
Reporter: Jan Riis
Created: Fri, 9 Jan 2004 8:02 AM
Updated: Sat, 10 Jan 2004 3:56 PM
Environment: DB2 vers. 7.2 on Win XP
Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.
<class name="dk.acure.journal.model.Skema">
...
<property name="xml" type="string" length="256000">
<column name="xml" sql-type="CLOB"/>
</property>
</class>
generates:
create table Skema (
...
xml CLOB,
);
But should be:
xml CLOB (256000)
Length is mandatory in DB2 (as far as I can see)
---------------------------------------------------------------------
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...> - 2004-01-10 17:26:24
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 11:25 AM
I applied this patch
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-608
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-608
Summary: Allow criteria queries on abstract classes from table-per-concrete-class mappings
Type: Improvement
Status: Closed
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Fix Fors:
2.1.2
Versions:
2.1.1
Assignee: Gavin King
Reporter: Shorn Tolley
Created: Mon, 5 Jan 2004 11:09 PM
Updated: Sat, 10 Jan 2004 11:25 AM
Environment: Hibernate 2.1.1, Ingres 2.6 SP2
Description:
I'm mapping a part of my domain model using the table-per-concrete-class strategy. I need to use hibernate's "implicit polymorphism" feature to query on the abstract class in the hierarchy to return specific instances of the class regardless of their concrete type.
I can do it using the HQL query mechanism (as long as I fully qualify the name of the abstract class), but when I try to use the Criteria query mechanism I get a mapping exception with a "No persisten for: <Classname>" type message.
The relevant section in the 2.1.1 documentation is "Chapter 16 Inheritance mappings".
I posted my problem in a forum topic and am raising this issue as a result of instructions given by the hibernate team: http://forum.hibernate.org/viewtopic.php?t=926608
Even if you don't want to implement the functionality I'm talking about (or want to delay it's implementation for a while), it might be a good idea to update the table in the limitations section for the "polymorphic load()/get()" column that says "use a query" to note that you can't use a criteria query.
It also might be worth mentioning that you need to use the fully qualified classname of the abstract class in the HQL query.
---------------------------------------------------------------------
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...> - 2004-01-10 16:45:28
|
The following issue has been updated:
Updater: Michael Gloegl (mailto:gl...@ok...)
Date: Sat, 10 Jan 2004 10:45 AM
Comment:
Grr, stupid Eclipse generate Patch does not seem to work right. Another try with commandline diff.
Changes:
Attachment changed to table_generator_if_exists_v2.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-615
Summary: Make SchemaExport use "IF EXISTS" for generators - Includes Patch
Type: Improvement
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1.1
Assignee:
Reporter: Michael Gloegl
Created: Sat, 10 Jan 2004 10:20 AM
Updated: Sat, 10 Jan 2004 10:45 AM
Environment: Hibernate 2.1.1
Description:
When droping tables for HiLo and other TableGenerators, the IF EXISTS syntax should be used if the Dialect supports it.
---------------------------------------------------------------------
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...> - 2004-01-10 16:33:25
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 10 Jan 2004 10:33 AM
Body:
The diff is broken.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-615
Summary: Make SchemaExport use "IF EXISTS" for generators - Includes Patch
Type: Improvement
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1.1
Assignee:
Reporter: Michael Gloegl
Created: Sat, 10 Jan 2004 10:20 AM
Updated: Sat, 10 Jan 2004 10:33 AM
Environment: Hibernate 2.1.1
Description:
When droping tables for HiLo and other TableGenerators, the IF EXISTS syntax should be used if the Dialect supports it.
---------------------------------------------------------------------
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...> - 2004-01-10 16:33:25
|
The following comment has been added to this issue:
Author: Gavin King
Created: Sat, 10 Jan 2004 10:32 AM
Body:
oh i get it ... its easy:
<property name="xml" type="text" length="12345"/>
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-612
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-612
Summary: SchemaExport: DB2 CLOB fails
Type: Bug
Status: Closed
Priority: Blocker
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1
Assignee:
Reporter: Jan Riis
Created: Fri, 9 Jan 2004 8:02 AM
Updated: Sat, 10 Jan 2004 10:32 AM
Environment: DB2 vers. 7.2 on Win XP
Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.
<class name="dk.acure.journal.model.Skema">
...
<property name="xml" type="string" length="256000">
<column name="xml" sql-type="CLOB"/>
</property>
</class>
generates:
create table Skema (
...
xml CLOB,
);
But should be:
xml CLOB (256000)
Length is mandatory in DB2 (as far as I can see)
---------------------------------------------------------------------
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...> - 2004-01-10 16:22:25
|
The following issue has been updated:
Updater: Michael Gloegl (mailto:gl...@ok...)
Date: Sat, 10 Jan 2004 10:21 AM
Changes:
Attachment changed to table_generator_if_exists.patch
---------------------------------------------------------------------
For a full history of the issue, see:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615&page=history
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-615
Summary: Make SchemaExport use "IF EXISTS" for generators - Includes Patch
Type: Improvement
Status: Unassigned
Priority: Minor
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1.1
Assignee:
Reporter: Michael Gloegl
Created: Sat, 10 Jan 2004 10:20 AM
Updated: Sat, 10 Jan 2004 10:21 AM
Environment: Hibernate 2.1.1
Description:
When droping tables for HiLo and other TableGenerators, the IF EXISTS syntax should be used if the Dialect supports it.
---------------------------------------------------------------------
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...> - 2004-01-10 16:20:28
|
Message: A new issue has been created in JIRA. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-615 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-615 Summary: Make SchemaExport use "IF EXISTS" for generators - Includes Patch Type: Improvement Status: Unassigned Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: toolset Versions: 2.1.1 Assignee: Reporter: Michael Gloegl Created: Sat, 10 Jan 2004 10:20 AM Updated: Sat, 10 Jan 2004 10:20 AM Environment: Hibernate 2.1.1 Description: When droping tables for HiLo and other TableGenerators, the IF EXISTS syntax should be used if the Dialect supports it. --------------------------------------------------------------------- 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...> - 2004-01-10 15:54:24
|
The following comment has been added to this issue:
Author: Max Rydahl Andersen
Created: Sat, 10 Jan 2004 9:53 AM
Body:
bummer - workaround is to have seperate hbm.xml files for it.
(og jan, du kan lave det med filters i edp ;) (a small danish direct comment ;)
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-612
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-612
Summary: SchemaExport: DB2 CLOB fails
Type: Bug
Status: Closed
Priority: Blocker
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1
Assignee:
Reporter: Jan Riis
Created: Fri, 9 Jan 2004 8:02 AM
Updated: Sat, 10 Jan 2004 9:53 AM
Environment: DB2 vers. 7.2 on Win XP
Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.
<class name="dk.acure.journal.model.Skema">
...
<property name="xml" type="string" length="256000">
<column name="xml" sql-type="CLOB"/>
</property>
</class>
generates:
create table Skema (
...
xml CLOB,
);
But should be:
xml CLOB (256000)
Length is mandatory in DB2 (as far as I can see)
---------------------------------------------------------------------
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...> - 2004-01-10 15:24:25
|
The following comment has been added to this issue:
Author: Jan Riis
Created: Sat, 10 Jan 2004 9:22 AM
Body:
... but this does not work on Oracle 9.2 (which we also use)!
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-612
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-612
Summary: SchemaExport: DB2 CLOB fails
Type: Bug
Status: Closed
Priority: Blocker
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
toolset
Versions:
2.1
Assignee:
Reporter: Jan Riis
Created: Fri, 9 Jan 2004 8:02 AM
Updated: Sat, 10 Jan 2004 9:22 AM
Environment: DB2 vers. 7.2 on Win XP
Description:
When using DB2 dialect, the generated schema (DDL)for CLOB fields does not include a "length" specification.
<class name="dk.acure.journal.model.Skema">
...
<property name="xml" type="string" length="256000">
<column name="xml" sql-type="CLOB"/>
</property>
</class>
generates:
create table Skema (
...
xml CLOB,
);
But should be:
xml CLOB (256000)
Length is mandatory in DB2 (as far as I can see)
---------------------------------------------------------------------
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...> - 2004-01-10 12:10:25
|
The following comment has been added to this issue:
Author: William Drai
Created: Sat, 10 Jan 2004 6:09 AM
Body:
I'm really sorry, I've not read the doc enough.
It is stated that this behaviour should be okay for most purposes.
I do agree with that for the <component>, but the <composite-element> is slighly different. With this null value semantic, you can have strange things like null elements in lists or in maps. This is really inconvenient and that would be nice to have an option like <composite-element null-value="empty"> or something like that.
Thank you for your help.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-613
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-613
Summary: Problem with null composite-elements
Type: Bug
Status: Closed
Priority: Minor
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Versions:
2.1 final
Assignee:
Reporter: William Drai
Created: Fri, 9 Jan 2004 9:52 AM
Updated: Sat, 10 Jan 2004 6:09 AM
Environment: Hibernate 2.1, MySQL 4.1.1
Description:
I have a mapping like this :
<class name="Foo">
<id ../>
<map name="elements" table="ELEMENTS">
<key column="FOO_ID" />
<index column="ELEMENT_ID" />
<composite-element class="Element">
<property name="prop1" />
<property name="prop2" />
</composite-element>
</map>
</class>
If I store an instance of Foo with one element in the map where prop1 and prop2 are null, all is ok in the database :
ELEMENT_ID | PROP1 | PROP2
"element" | null | null
When I load this instance of Foo later, I get the "elements" map, but the entry has a key "element" and a null value, instead having a new empty Element instance.
William
---------------------------------------------------------------------
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...> - 2004-01-10 12:05:32
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 6:03 AM
Well, actually, I take that back.
The new machinery in 2.1.2 makes it easy to implement this (I think). So please test my fix attempt in the current v21branch in CVS.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Fix Fors:
2.1.2
Assignee: Gavin King
Reporter: Richard Scranton
Created: Thu, 20 Nov 2003 1:22 PM
Updated: Sat, 10 Jan 2004 6:03 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...> - 2004-01-10 12:03:30
|
Message: The following issue has been reopened. --------------------------------------------------------------------- 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: Reopened Priority: Major Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: core Assignee: Gavin King Reporter: Richard Scranton Created: Thu, 20 Nov 2003 1:22 PM Updated: Sat, 10 Jan 2004 6:02 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...> - 2004-01-10 11:45:25
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 5:44 AM
I finally applied this patch (with adjustments).
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-380
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-380
Summary: Use ResultSet.getGeneratedKeys() when supported by JDBC driver
Type: Improvement
Status: Closed
Priority: Minor
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Fix Fors:
2.1.2
Versions:
2.1
Assignee: Gavin King
Reporter: David Morris
Created: Sat, 4 Oct 2003 1:02 AM
Updated: Sat, 10 Jan 2004 5:44 AM
Environment: JDBC 3.0 Drivers with 1.4 JDKs. MySql and DB2 both have JDBC drivers that support get generated keys.
Description:
Retrieve ResultSet of natively generated keys after inserting records into databases that provide this support. Performance is genrally better with this technique. The code change should be backward compatable with 1.3 JREs and older JDBC drivers.
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://opensource.atlassian.com/projects/hibernate/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
|
|
From: <leg...@at...> - 2004-01-10 11:26:24
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 5:25 AM
Applied (as part of HB-380)
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: FIXED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Fix Fors:
2.1.2
Versions:
2.1 beta 4
Assignee: Gavin King
Reporter: John Kristian
Created: Thu, 30 Oct 2003 1:20 PM
Updated: Sat, 10 Jan 2004 5:25 AM
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...> - 2004-01-10 11:20:25
|
Message: The following issue has been closed. --------------------------------------------------------------------- View the issue: http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-591 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-591 Summary: Extra documentation to indicate multi-column indexes are possible Type: Patch Status: Closed Priority: Minor Resolution: FIXED Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Fix Fors: 2.1.2 Assignee: Christian Bauer Reporter: Francois Beausoleil Created: Wed, 31 Dec 2003 7:53 AM Updated: Sat, 10 Jan 2004 5:18 AM Environment: Tested on Hibernate 2.0.2 Description: The following patch adds documentation explaining to the user that it is possible to have the SchemaExport tool automatically create indexes. This patch is a followup to the following thread: http://forum.hibernate.org/viewtopic.php?t=926694 Index: doc/reference/src/basic_or_mapping.xml =================================================================== RCS file: /cvsroot/hibernate/Hibernate2/doc/reference/src/basic_or_mapping.xml,v retrieving revision 1.30 diff -u -r1.30 basic_or_mapping.xml --- doc/reference/src/basic_or_mapping.xml 1 Aug 2003 16:33:06 -0000 1.30 +++ doc/reference/src/basic_or_mapping.xml 31 Dec 2003 13:50:09 -0000 @@ -1718,6 +1718,27 @@ unique="true"/> </property>]]></programlisting> + + <para> + Finally, it is also possible to have the <literal>SchemaExport</literal> commandline tool generated + required indexes automatically. For this, use the <literal>index</literal> attribute on + <literal><column></literal> elements. + </para> + + <programlisting><![CDATA[<property + name="lastname"> + <column + name="LASTNAME" + index="by_last_first"/> +</property> + +<property + name="firstname"> + <column + name="FIRSTNAME" + index="by_last_first"/> +</property>]]></programlisting> + </sect1> --------------------------------------------------------------------- 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...> - 2004-01-10 08:55:28
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 2:54 AM
CLosing this issue, since Sybase should fix their driver.
---------------------------------------------------------------------
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: Closed
Priority: Major
Resolution: WON'T FIX
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Components:
core
Assignee:
Reporter: Richard Scranton
Created: Thu, 20 Nov 2003 1:22 PM
Updated: Sat, 10 Jan 2004 2:54 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...> - 2004-01-10 08:53:24
|
Message:
The following issue has been closed.
Resolver: Gavin King
Date: Sat, 10 Jan 2004 2:52 AM
The user did not respond, so assume that this is caused by incorrect session handling.
---------------------------------------------------------------------
View the issue:
http://opensource.atlassian.com/projects/hibernate/secure/ViewIssue.jspa?key=HB-572
Here is an overview of the issue:
---------------------------------------------------------------------
Key: HB-572
Summary: net.sf.hibernate.AssertionFailure: Hibernate has a bug processing collections
Type: Bug
Status: Closed
Priority: Major
Resolution: REJECTED
Original Estimate: Unknown
Time Spent: Unknown
Remaining: Unknown
Project: Hibernate2
Versions:
2.1
Assignee:
Reporter: Raider Yang
Created: Fri, 19 Dec 2003 9:41 AM
Updated: Sat, 10 Jan 2004 2:52 AM
Environment: tomcat+mysql
Description:
at java.lang.Thread.run(Thread.java:536)
net.sf.hibernate.AssertionFailure: Hibernate has a bug processing collections
at net.sf.hibernate.impl.SessionImpl.prepareCollectionForUpdate(SessionImpl.java:2635)
at net.sf.hibernate.impl.SessionImpl.updateReachableCollection(SessionImpl.java:2556)
at net.sf.hibernate.impl.SessionImpl.updateReachable(SessionImpl.java:2577)
at net.sf.hibernate.impl.SessionImpl.updateReachables(SessionImpl.java:2682)
at net.sf.hibernate.impl.SessionImpl.flushEntities(SessionImpl.java:2259)
at net.sf.hibernate.impl.SessionImpl.flushEverything(SessionImpl.java:2017)
at net.sf.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:1560)
at net.sf.hibernate.impl.SessionImpl.getQueries(SessionImpl.java:1372)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1332)
at net.sf.hibernate.impl.SessionImpl.find(SessionImpl.java:1322)
---------------------------------------------------------------------
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...> - 2004-01-10 08:51: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-566 Here is an overview of the issue: --------------------------------------------------------------------- Key: HB-566 Summary: Simple patch for HB-560 and HB-561 Type: Patch Status: Open Priority: Minor Original Estimate: Unknown Time Spent: Unknown Remaining: Unknown Project: Hibernate2 Components: core Versions: 2.1 Assignee: Gavin King Reporter: William Drai Created: Wed, 17 Dec 2003 11:27 AM Updated: Sat, 10 Jan 2004 2:50 AM 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.
