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: Max R. A. (JIRA) <no...@at...> - 2006-06-07 15:04:17
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-685?page=comments#action_23290 ] Max Rydahl Andersen commented on HBX-685: ----------------------------------------- ok, could you show the full stacktrace ? in ant: ant -verbose in eclipse: look in the error log view > Reverse Engineering Strategy cannot find constructor > ---------------------------------------------------- > > Key: HBX-685 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-685 > Project: Hibernate Tools > Type: Bug > Components: reverse-engineer > Versions: 3.1.beta5 > Reporter: Matt Read > Attachments: ExampleStrategy.java > > > The custom reverse engineering strategy I was using on 3.1beta4 fails with the following error on beta 5. I've tried pasting the "ExampleStrategy" from the documentation (http://www.hibernate.org/hib_docs/tools/reference/en/html/reverseengineering.html#custom-reveng-strategy) and that fails too. > "Could not create or find com.xxx.ExampleStrategy with one argument delegate constructor" -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Matt R. (JIRA) <no...@at...> - 2006-06-07 15:00:20
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-685?page=all ] Matt Read updated HBX-685: -------------------------- Attachment: ExampleStrategy.java I used the one in the documentation which also fails with the same error as mine... attached. > Reverse Engineering Strategy cannot find constructor > ---------------------------------------------------- > > Key: HBX-685 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-685 > Project: Hibernate Tools > Type: Bug > Components: reverse-engineer > Versions: 3.1.beta5 > Reporter: Matt Read > Attachments: ExampleStrategy.java > > > The custom reverse engineering strategy I was using on 3.1beta4 fails with the following error on beta 5. I've tried pasting the "ExampleStrategy" from the documentation (http://www.hibernate.org/hib_docs/tools/reference/en/html/reverseengineering.html#custom-reveng-strategy) and that fails too. > "Could not create or find com.xxx.ExampleStrategy with one argument delegate constructor" -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Max R. A. (JIRA) <no...@at...> - 2006-06-07 14:20:31
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-685?page=comments#action_23288 ] Max Rydahl Andersen commented on HBX-685: ----------------------------------------- how does you strategy looks like ? > Reverse Engineering Strategy cannot find constructor > ---------------------------------------------------- > > Key: HBX-685 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-685 > Project: Hibernate Tools > Type: Bug > Components: reverse-engineer > Versions: 3.1.beta5 > Reporter: Matt Read > > > The custom reverse engineering strategy I was using on 3.1beta4 fails with the following error on beta 5. I've tried pasting the "ExampleStrategy" from the documentation (http://www.hibernate.org/hib_docs/tools/reference/en/html/reverseengineering.html#custom-reveng-strategy) and that fails too. > "Could not create or find com.xxx.ExampleStrategy with one argument delegate constructor" -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Matt R. (JIRA) <no...@at...> - 2006-06-07 14:10:33
|
Reverse Engineering Strategy cannot find constructor
----------------------------------------------------
Key: HBX-685
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-685
Project: Hibernate Tools
Type: Bug
Components: reverse-engineer
Versions: 3.1.beta5
Reporter: Matt Read
The custom reverse engineering strategy I was using on 3.1beta4 fails with the following error on beta 5. I've tried pasting the "ExampleStrategy" from the documentation (http://www.hibernate.org/hib_docs/tools/reference/en/html/reverseengineering.html#custom-reveng-strategy) and that fails too.
"Could not create or find com.xxx.ExampleStrategy with one argument delegate constructor"
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 22:52:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-361?page=all ] Emmanuel Bernard reopened ANN-361: ---------------------------------- > @Column(name="xxxx") does not work when composit key is used > ------------------------------------------------------------ > > Key: ANN-361 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-361 > Project: Hibernate Annotations > Type: Bug > Versions: 3.2.0.cr1 > Reporter: Thomas Risberg > > > When using a composit key and specifying name of id column - the specified name is ignored and a column with the name of the field is generated. > This: > ------------- > import java.io.Serializable; > public class ProductItemPK implements Serializable { > private Long productId; > private Long itemId; > } > ------------- > import javax.persistence.*; > @Entity > @IdClass(value=ProductItemPK.class) > public class ProductItem { > @Id > @Column(name="product_id") > private Long productId; > @Id > @Column(name="item_id") > private Long itemId; > private String name; > } > ------------- > results in: > create table ProductItem ( > productId number(19,0) not null, > itemId number(19,0) not null, > name varchar2(255 char), > primary key (productId, itemId) > ) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 22:52:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-361?page=comments#action_23287 ] Emmanuel Bernard commented on ANN-361: -------------------------------------- If the TCK complains, I will :-) I'm opened to patches, but this is not my priority > @Column(name="xxxx") does not work when composit key is used > ------------------------------------------------------------ > > Key: ANN-361 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-361 > Project: Hibernate Annotations > Type: Bug > Versions: 3.2.0.cr1 > Reporter: Thomas Risberg > > > When using a composit key and specifying name of id column - the specified name is ignored and a column with the name of the field is generated. > This: > ------------- > import java.io.Serializable; > public class ProductItemPK implements Serializable { > private Long productId; > private Long itemId; > } > ------------- > import javax.persistence.*; > @Entity > @IdClass(value=ProductItemPK.class) > public class ProductItem { > @Id > @Column(name="product_id") > private Long productId; > @Id > @Column(name="item_id") > private Long itemId; > private String name; > } > ------------- > results in: > create table ProductItem ( > productId number(19,0) not null, > itemId number(19,0) not null, > name varchar2(255 char), > primary key (productId, itemId) > ) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 22:39:22
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1818?page=all ] Steve Ebersole closed HHH-1818: ------------------------------- Resolution: Fixed > remove() should force subsequent contains() calls to return false > ----------------------------------------------------------------- > > Key: HHH-1818 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1818 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0 > > > Currently: > session.remove( entity ); > session.contains( entity ); > reports that the entity is still contained in the session. Conceptually, this is not correct. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Thomas R. (JIRA) <no...@at...> - 2006-06-06 21:34:37
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-361?page=comments#action_23286 ] Thomas Risberg commented on ANN-361: ------------------------------------ Looking at the JPA Spec page 196, Example 2 - here the annotations are applied the same way I have them applied in my example. Does this mean that you are not going to support this? Wouldn't that in turn indicate that you would not be fully spec compliant? Any clarification would be helpful. Thanks, >From the JPA Spec page 196: Example 2: OneToOne relationship between Employee and EmployeeInfo classes public class EmpPK { public Integer id; public String name; } @Entity @IdClass(com.acme.EmpPK.class) public class Employee { @Id Integer id; @Id String name; @OneToOne @PrimaryKeyJoinColumns({ @PrimaryKeyJoinColumn(name="ID", referencedColumn-Name="EMP_ID"), @PrimaryKeyJoinColumn(name="NAME", referencedColumn-Name="EMP_NAME")}) EmployeeInfo info; ... } @Entity @IdClass(com.acme.EmpPK.class) public class EmployeeInfo { @Id @Column(name="EMP_ID") Integer id; @Id @Column(name="EMP_NAME") String name; ... } > @Column(name="xxxx") does not work when composit key is used > ------------------------------------------------------------ > > Key: ANN-361 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-361 > Project: Hibernate Annotations > Type: Bug > Versions: 3.2.0.cr1 > Reporter: Thomas Risberg > > > When using a composit key and specifying name of id column - the specified name is ignored and a column with the name of the field is generated. > This: > ------------- > import java.io.Serializable; > public class ProductItemPK implements Serializable { > private Long productId; > private Long itemId; > } > ------------- > import javax.persistence.*; > @Entity > @IdClass(value=ProductItemPK.class) > public class ProductItem { > @Id > @Column(name="product_id") > private Long productId; > @Id > @Column(name="item_id") > private Long itemId; > private String name; > } > ------------- > results in: > create table ProductItem ( > productId number(19,0) not null, > itemId number(19,0) not null, > name varchar2(255 char), > primary key (productId, itemId) > ) -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 20:15:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-684?page=comments#action_23285 ] Emmanuel Bernard commented on HBX-684: -------------------------------------- you're right. http://www.faqs.org/rfcs/rfc822.html 3.3 (atom) A patch would speed the fix release > @Email validator failed a valid email address > --------------------------------------------- > > Key: HBX-684 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-684 > Project: Hibernate Tools > Type: Bug > Environment: JBoss 4.0.4.GA > Reporter: Jeff Schnitzer > > > @Email validation failed this email adddress: > SRS0=aHFE=YF=pobox.com=fr...@bo... > It looks valid to me. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 19:54:28
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815?page=comments#action_23284 ] Emmanuel Bernard commented on HHH-1815: --------------------------------------- To be more specific, Hibernate seems to handle transparently batch operations already since it uses JDBC batch update underneath. Did you try it? It is defeated if you use a generator that requires an intermetdiate SQL operation inbetween (like sequence). But for batch operation, you should consider hilo or seqhilo anyway. > Add support for batch operations in StatelessSession > ---------------------------------------------------- > > Key: HHH-1815 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815 > Project: Hibernate3 > Type: Improvement > Components: core > Environment: all > Reporter: Eric Williams > Assignee: Steve Ebersole > Priority: Minor > > > The principal use cases for StatelessSession seems to be in batch-oriented processing. However, there is no support for batch inserts or updates of persistent entities in the StatelessSession interface. This severely handicaps its usefulness for batch data loading. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 19:22:26
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815?page=comments#action_23283 ] Emmanuel Bernard commented on HHH-1815: --------------------------------------- No, this should be taken care of transparently by Hibernate. > Add support for batch operations in StatelessSession > ---------------------------------------------------- > > Key: HHH-1815 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815 > Project: Hibernate3 > Type: Improvement > Components: core > Environment: all > Reporter: Eric Williams > Assignee: Steve Ebersole > Priority: Minor > > > The principal use cases for StatelessSession seems to be in batch-oriented processing. However, there is no support for batch inserts or updates of persistent entities in the StatelessSession interface. This severely handicaps its usefulness for batch data loading. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 19:20:24
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1818?page=comments#action_23282 ] Steve Ebersole commented on HHH-1818: ------------------------------------- Similiar issue for remove() followed by load operation performed from the API. Currently this throws exceptions; should return null. > remove() should force subsequent contains() calls to return false > ----------------------------------------------------------------- > > Key: HHH-1818 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1818 > Project: Hibernate3 > Type: Improvement > Components: core > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0 > > > Currently: > session.remove( entity ); > session.contains( entity ); > reports that the entity is still contained in the session. Conceptually, this is not correct. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Jeff S. (JIRA) <no...@at...> - 2006-06-06 18:42:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-684?page=comments#action_23281 ] Jeff Schnitzer commented on HBX-684: ------------------------------------ Too slammed right now to find the spec entry, but I can tell you that every EZMLM system (and I think Mailman too) creates VERP addresses that look like this: <issues-return-103-jeff=inf...@su...> So no matter what the spec says, '=' is in widespread use. I'd be really surprised if it's invalid. > @Email validator failed a valid email address > --------------------------------------------- > > Key: HBX-684 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-684 > Project: Hibernate Tools > Type: Bug > Environment: JBoss 4.0.4.GA > Reporter: Jeff Schnitzer > > > @Email validation failed this email adddress: > SRS0=aHFE=YF=pobox.com=fr...@bo... > It looks valid to me. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 18:40:31
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815?page=comments#action_23280 ] Steve Ebersole commented on HHH-1815: ------------------------------------- Yes, I have been giving this thought already. It is really needed for StatelessSession to be as useful as it could be in terms of performance. Unfortunately I am bogged down in JPA stuff right now. Please have a look and feel free to submit a patch in the meantime. > Add support for batch operations in StatelessSession > ---------------------------------------------------- > > Key: HHH-1815 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815 > Project: Hibernate3 > Type: Improvement > Components: core > Environment: all > Reporter: Eric Williams > Priority: Minor > > > The principal use cases for StatelessSession seems to be in batch-oriented processing. However, there is no support for batch inserts or updates of persistent entities in the StatelessSession interface. This severely handicaps its usefulness for batch data loading. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 18:40:31
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815?page=all ] Steve Ebersole reopened HHH-1815: --------------------------------- Assign To: Steve Ebersole > Add support for batch operations in StatelessSession > ---------------------------------------------------- > > Key: HHH-1815 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815 > Project: Hibernate3 > Type: Improvement > Components: core > Environment: all > Reporter: Eric Williams > Assignee: Steve Ebersole > Priority: Minor > > > The principal use cases for StatelessSession seems to be in batch-oriented processing. However, there is no support for batch inserts or updates of persistent entities in the StatelessSession interface. This severely handicaps its usefulness for batch data loading. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Bruce A. (JIRA) <no...@at...> - 2006-06-06 18:32:38
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739?page=comments#action_23279 ] Bruce Atherton commented on HHH-1739: ------------------------------------- Thanks for opening this issue, Kirk. Since I've had no luck convincing the powers that be to reopen HB-1246, perhaps we can move forward with this one. It sounds like there are at least two situations that can expose this deadlock: having more threads than database connections, and having deep object graphs. I think that both situations are resolved if it is possible to configure hibernate to use a separate data source for id generation. I've started down this path in the code, and it seems eminently doable. If the reason the issue isn't being addressed is the need for a patch, let me know and I'll finish adding the feature and generate one. I don't want to go to the effort, though, if it is just going to be ignored. So my question is, do the hibernate developers agree in principle with the idea of allowing for a separate data source for ID generation so that we can remove this deadlock from the design of hibernate? Would anyone be willing to commit such a patch? > HILO id can cause deadlock: Part deux > ------------------------------------- > > Key: HHH-1739 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1739 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3 > Environment: Hibernate 3.1.3 running JDK 1.4.1_07 Solaris 5.8 > Adaptive Server Enterprise/12.5.2/EBF 12054 ESD#2/P/Sun_svr4/OS 5.8/ase1252/1844/64-bit/FBO/Thu Aug 12 10:51:11 2004 > Reporter: Kirk Rasmussen > > Original Estimate: 1 minute > Remaining: 1 minute > > This is mostly a duplicate of HB-1246 but with a twist. I believe that there is a flaw in Hibernate's design for how it generates ids for some dialects. This is a particular problem for deep object graphs and/or at high volume. Or at least it is a problem for those of us stuck on the crappy Sybase platform. > We have an application that creates hundreds of objects that need ids generated within a single transaction. It is quite common for us to potentially exhaust the connection pool with a deep object graph. We are persisting a Trade object which has a complex and deep object graph (upwards of 100s of persistent objects). Within each trade there are roughly 15 classes which need generated ids with 30 or more instances of each class in some cases. > IMO The design flaw is when the ids are generated. From quickly browsing the source it seems that they are being generated on the fly as the objects are being processed. This can result in running of out database connections when under load or when a particular trade has a large number of persistent object instances and deadlocking the system. > A better design would be if the ids could be generated for all tables in a single transaction up front rather than issuing a whole bunch of individual transactions for each table and object. > I believe that TOPLink generates all its ids up front to avoid the described resource thrashing. It also has the configuration to generate ids from within the same transaction as the original unit of work or from a secondary unit of work. > See org.hibernate.id.MultipleHiLoPerTableGenerator -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Eric W. (JIRA) <no...@at...> - 2006-06-06 18:32:30
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815?page=comments#action_23278 ] Eric Williams commented on HHH-1815: ------------------------------------ I'm not sure I understand the use of an update query. If you're referring to the use of INSERT INTO ... SELECT FROM, that's not what I'm trying to get at. My essential problem with StatelessSession is that I can't batch-insert objects that I have in memory. Currently, I can only insert(object), not insert(array of objects). The enhancement request was to provide capability to insert(array of objects), using appropriate JDBC batching. Is this somehow accomplishable with Query.executeUpdate()? > Add support for batch operations in StatelessSession > ---------------------------------------------------- > > Key: HHH-1815 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1815 > Project: Hibernate3 > Type: Improvement > Components: core > Environment: all > Reporter: Eric Williams > Priority: Minor > > > The principal use cases for StatelessSession seems to be in batch-oriented processing. However, there is no support for batch inserts or updates of persistent entities in the StatelessSession interface. This severely handicaps its usefulness for batch data loading. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 18:22:27
|
remove() should force subsequent contains() calls to return false
-----------------------------------------------------------------
Key: HHH-1818
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1818
Project: Hibernate3
Type: Improvement
Components: core
Reporter: Steve Ebersole
Assigned to: Steve Ebersole
Fix For: 3.2.0
Currently:
session.remove( entity );
session.contains( entity );
reports that the entity is still contained in the session. Conceptually, this is not correct.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 17:30:37
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669?page=all ] Steve Ebersole closed HHH-1669: ------------------------------- Fix Version: 3.2.0 Resolution: Duplicate > TransactionHelper leaves JDBC connections unclosed, when the connection is set to autocommit false > -------------------------------------------------------------------------------------------------- > > Key: HHH-1669 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0 cr1 > Environment: Hibernate 3.2.0 CR1 > Reporter: julio rincon > > > The Isolater.JdbcDelegate class's delegateWork(...) method leaves the JDBC Connection open causing a lekage. Specifically, the connection is left open only when the Connection was set to autocommit false. > The escenario in which the problem is experienced is when a TransactionHelper subclass is implemented for instance to generate custom identifiers, the TransactionHelper provides the doWorkInNewTransaction method to ensure that the ID generation is done in a separate transaction and always commited. The mentioned method uses the Isolater class for this purpose. > This is the patch: > Index: src/org/hibernate/engine/transaction/Isolater.java > =================================================================== > --- src/org/hibernate/engine/transaction/Isolater.java (revision 9747) > +++ src/org/hibernate/engine/transaction/Isolater.java (working copy) > @@ -185,9 +185,9 @@ > } > catch( Throwable ignore ) { > log.trace( "was unable to reset connection back to auto-commit" ); > - } > - session.getBatcher().closeConnection( connection ); > + } > } > + session.getBatcher().closeConnection( connection ); > } > } > } > Cheers > Julio. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 17:30:36
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669?page=all ] Steve Ebersole closed HHH-1669: ------------------------------- Fix Version: (was: 3.2.0) Resolution: Duplicate > TransactionHelper leaves JDBC connections unclosed, when the connection is set to autocommit false > -------------------------------------------------------------------------------------------------- > > Key: HHH-1669 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0 cr1 > Environment: Hibernate 3.2.0 CR1 > Reporter: julio rincon > > > The Isolater.JdbcDelegate class's delegateWork(...) method leaves the JDBC Connection open causing a lekage. Specifically, the connection is left open only when the Connection was set to autocommit false. > The escenario in which the problem is experienced is when a TransactionHelper subclass is implemented for instance to generate custom identifiers, the TransactionHelper provides the doWorkInNewTransaction method to ensure that the ID generation is done in a separate transaction and always commited. The mentioned method uses the Isolater class for this purpose. > This is the patch: > Index: src/org/hibernate/engine/transaction/Isolater.java > =================================================================== > --- src/org/hibernate/engine/transaction/Isolater.java (revision 9747) > +++ src/org/hibernate/engine/transaction/Isolater.java (working copy) > @@ -185,9 +185,9 @@ > } > catch( Throwable ignore ) { > log.trace( "was unable to reset connection back to auto-commit" ); > - } > - session.getBatcher().closeConnection( connection ); > + } > } > + session.getBatcher().closeConnection( connection ); > } > } > } > Cheers > Julio. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 17:30:36
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669?page=all ] Steve Ebersole reopened HHH-1669: --------------------------------- > TransactionHelper leaves JDBC connections unclosed, when the connection is set to autocommit false > -------------------------------------------------------------------------------------------------- > > Key: HHH-1669 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1669 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.2.0 cr1 > Environment: Hibernate 3.2.0 CR1 > Reporter: julio rincon > > > The Isolater.JdbcDelegate class's delegateWork(...) method leaves the JDBC Connection open causing a lekage. Specifically, the connection is left open only when the Connection was set to autocommit false. > The escenario in which the problem is experienced is when a TransactionHelper subclass is implemented for instance to generate custom identifiers, the TransactionHelper provides the doWorkInNewTransaction method to ensure that the ID generation is done in a separate transaction and always commited. The mentioned method uses the Isolater class for this purpose. > This is the patch: > Index: src/org/hibernate/engine/transaction/Isolater.java > =================================================================== > --- src/org/hibernate/engine/transaction/Isolater.java (revision 9747) > +++ src/org/hibernate/engine/transaction/Isolater.java (working copy) > @@ -185,9 +185,9 @@ > } > catch( Throwable ignore ) { > log.trace( "was unable to reset connection back to auto-commit" ); > - } > - session.getBatcher().closeConnection( connection ); > + } > } > + session.getBatcher().closeConnection( connection ); > } > } > } > Cheers > Julio. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 17:22:26
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1817?page=all ] Steve Ebersole closed HHH-1817: ------------------------------- Resolution: Fixed added and applied check to "derived select clause" > Introduce setting for JPA-QL strict compliance > ---------------------------------------------- > > Key: HHH-1817 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1817 > Project: Hibernate3 > Type: New Feature > Components: query-hql > Versions: 3.2.0.cr2 > Reporter: Steve Ebersole > Assignee: Steve Ebersole > Fix For: 3.2.0 > > > JPA-QL disallows certain things explicitly that HQL allows (ommission of select clause e.g.). Add a configuration flag (hibernate.query.jpaql_strict_compliance) to allow users to specify that they want strict compliance with JPA-QL in terms of query parsing. This is the non-default mode. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Steve E. (JIRA) <no...@at...> - 2006-06-06 17:19:28
|
Introduce setting for JPA-QL strict compliance
----------------------------------------------
Key: HHH-1817
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1817
Project: Hibernate3
Type: New Feature
Components: query-hql
Versions: 3.2.0.cr2
Reporter: Steve Ebersole
Assigned to: Steve Ebersole
Fix For: 3.2.0
JPA-QL disallows certain things explicitly that HQL allows (ommission of select clause e.g.). Add a configuration flag (hibernate.query.jpaql_strict_compliance) to allow users to specify that they want strict compliance with JPA-QL in terms of query parsing. This is the non-default mode.
--
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
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
|
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 17:19:27
|
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-684?page=comments#action_23276 ] Emmanuel Bernard commented on HBX-684: -------------------------------------- I'm gonna need to check the validity of = in an email. Are you sure this is possible? The spec chapter would be cool :-) > @Email validator failed a valid email address > --------------------------------------------- > > Key: HBX-684 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-684 > Project: Hibernate Tools > Type: Bug > Environment: JBoss 4.0.4.GA > Reporter: Jeff Schnitzer > > > @Email validation failed this email adddress: > SRS0=aHFE=YF=pobox.com=fr...@bo... > It looks valid to me. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
|
From: Emmanuel B. (JIRA) <no...@at...> - 2006-06-06 17:15:21
|
[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-357?page=all ] Emmanuel Bernard closed ANN-357: -------------------------------- > Hibernate does not respect batch setting (annotation) on collection for loading > ------------------------------------------------------------------------------- > > Key: ANN-357 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-357 > Project: Hibernate Annotations > Type: Bug > Environment: hibernate 3.1.3 (2006.03.20) Hibernate annotation 3.1 beta 8, 20.01.2006 > Reporter: neelabh > Priority: Minor > > > I have a list of portfolios and several collections (entries, quries, permissions) mapping. The collection are set for lazy initialization. I am using hibernate annotations > Bu#1 > When I load portfolio first time(a list of portfolio) then entries , queries and permission are not batched for query. Infact they are queried one by one like > portfolio1 > entry1 > permission1 > query1 > portfolio2 > entry2 > permission2 > query2 > Hibernate: select portfolio0_.portfolioId as portfoli1_0_0_, portfolio0_.name as name0_0_, portfolio0_.owner as owner0_0_, portfolio0_.currentDateTime as currentD4_0_0_, portfolio0_.TSportfolioId as TSportfo5_0_0_ from psPortfolio portfolio0_ where portfolio0_.portfolioId in (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) > Hibernate: select instrument0_.portfolioId as portfoli5_1_, instrument0_.entryId as entryId1_, instrument0_.entryId as entryId2_0_, instrument0_.portfolioId as portfoli5_2_0_, instrument0_.productType as productT2_2_0_, instrument0_.quantity as quantity2_0_, instrument0_.TSproductId as TSproduc4_2_0_ from psInstrumentEntry instrument0_ where instrument0_.portfolioId=? > Hibernate: select queryentri0_.portfolioId as portfoli4_1_, queryentri0_.entryId as entryId1_, queryentri0_.entryId as entryId1_0_, queryentri0_.portfolioId as portfoli4_1_0_, queryentri0_.name as name1_0_, queryentri0_.comment as comment1_0_ from psQueryEntry queryentri0_ where queryentri0_.portfolioId=? > Hibernate: select portfoliop0_.portfolioId as portfoli6_1_, portfoliop0_.portfolioPermissionId as portfoli1_1_, portfoliop0_.portfolioPermissionId as portfoli1_4_0_, portfoliop0_.portfolioId as portfoli6_4_0_, portfoliop0_.partyRefType as partyRef2_4_0_, portfoliop0_.partyId as partyId4_0_, portfoliop0_.partySubType as partySub4_4_0_, portfoliop0_.accessLevel as accessLe5_4_0_ from psPortfolioPermission portfoliop0_ where portfoliop0_.portfolioId=? > I am not sure what is wrong with setting however, when I delete or amend or insert are batched properly. > Can you please check > This is affecting performance of huge portfolio. > Bug#2 > Even if I wnat to initialize only entry, it loads queries and permissions both, Is there any way to prohibit using annotations. -- 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 - For more information on JIRA, see: http://www.atlassian.com/software/jira |
93 messages has been excluded from this view by a project administrator.
