March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3360) Custom Oracle Batcher to allow batch updates for versioned data

by Manuel Dominguez Sarmiento (JIRA)

Custom Oracle Batcher to allow batch updates for versioned data --------------------------------------------------------------- Key: HHH-3360 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3360 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga Environment: Oracle 10g R1, 10g R2, 11g R1 (have not tried previous Oracle versions), 11g R1 drivers (older drivers should also work) Reporter: Manuel Dominguez Sarmiento Priority: Minor Attachments: C3P0OracleBatchingBatcher.java, C3P0OracleBatchingBatcherFactory.java, OracleBatchingBatcher.java, OracleBatchingBatcherFactory.java We have developed a custom Oracle Batcher which allows batching versioned data. The Oracle JDBC driver does not return update counts when using the standard JDBC 2.0 batching mechanism, however the proprietary Oracle batching mechanism allows obtaining the total batch row update count. The update counts are absolutely necessary to detect stale updates. Although it is not exactly the same, the total row update count is actually enough information to be able to batch versioned data and still detect stale updates. We'd like to contribute the attached files. They have a compile time dependency on Oracle JDBC. If this is not acceptable, it could be easily solved by using reflection. Another Batcher is provided for when the Oracle connection is being managed through c3p0 (a common deployment scenario). This has a compile time dependency on c3p0. A few "dirty" tricks were necessary to pull this off without patching other classes. Specifically, it was necessary to override Java private semantics to obtain BasicExpectation.expectedRowCount. This could be easily solved by adding an accessor method to the Expectation interface. There is one issue which we are not completely sure of, however so far we have not found any problems. When the Expectation is NONE, there is no way to check whether the total row count is correct or not, even if other batched updates do have expectations with expected row counts. Our understanding is that actually, since batching requires all statements to be of the same type (since the same PreparedStatement / CallableStatement is being used), then either ALL expectations will be NONE, or all will have an expected row count. We'd welcome comments from the Hibernate team. This could also be probably handled better by improving the Expectation interface. Oracle JDBC docs that explain the Oracle batching model: http://download.oracle.com/docs/cd/B28359_01/java.111/b31224/oraperf.htm#... As expected, implementing this solution has resulted in drastical improvement in batch processing. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 1 month

4
11
0 / 0

[Hibernate-JIRA] Created: (ANN-644) @ManyToMany appears to ALWAYS generate a left outer join SQL

by Barry Davies (JIRA)

@ManyToMany appears to ALWAYS generate a left outer join SQL ------------------------------------------------------------ Key: ANN-644 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-644 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Reporter: Barry Davies Priority: Minor Attachments: files.zip A collection mapping created using the @ManyToMany JPA annotation appears to create a left outer join SQL regardless of whether the joinColumn or inverseJoinColumn are marked nullable or not. This might be in error. Emmanuel asked for a JIRA issue to be created, so here we are. I have attached some files that can recreate what I believe to be the issue. The forum topic where this was brought up is: http://forum.hibernate.org/viewtopic.php?t=977936 -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3160) Support one-to-many list associations with constraints on both (owner_id, position) and (child_id)

by Gail Badner (JIRA)

Support one-to-many list associations with constraints on both (owner_id, position) and (child_id) -------------------------------------------------------------------------------------------------- Key: HHH-3160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3160 Project: Hibernate3 Issue Type: Sub-task Reporter: Gail Badner Assignee: Gail Badner The logic used for removing entities from one-to-many list associations can cause ConstraintViolationException will be thrown if there are constraints on both (owner_id, position) and (child_id) in the "collection table". If the association is on a join table, the "collection table" is the join table; otherwise, the "collection table" is the child entity table.. Currently, SchemaExport does not put a constraint on (owner_id, position) when exporting one-to-many list associations on a foreign key. SchemaExport should be updated to also export this constraint. See HHH-1268 for a description of how to reproduce this issue. For one-to-many list associations on a foreign key, the workaround is to either define the constraint on (owner_id, position) in the child entity table as deferred. If this is not on option for a particular Dialect, the constraint on (owner_id, position) will have to be excluded. For a one-to-many list association on a join table, the workaround is to either define the constraint on (child_id) in the join table as deferred. If this is not on option for a particular Dialect, the constraint on (child_id) will have to be excluded. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5963) TS:Oracle, PostgreSQL: Transaction#commit() throws TransientObjectException, expected JDBCexception - MultiPathCircleCascadeCheckNullibilityFalseTest

by Ondrej Zizka (JIRA)

TS:Oracle, PostgreSQL: Transaction#commit() throws TransientObjectException, expected JDBCexception - MultiPathCircleCascadeCheckNullibilityFalseTest ----------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5963 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5963 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.2 Environment: Oracle 10g PostgreSQL 8.2, 8.3 Reporter: Ondrej Zizka Assignee: Strong Liu In MultiPathCircleCascadeCheckNullibilityFalseTest#testMergeEntityWithNonNullableTransientEntity(), TransientObjectException is thrown on commit, whilst JDBCException is expected. For other DBs, it behaves as expectd. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5785) HQL UPDATE omits alias when referencing an entity

by Ondrej Medek (JIRA)

HQL UPDATE omits alias when referencing an entity ------------------------------------------------- Key: HHH-5785 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5785 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 in JBoss AS 5.1.0, org.hibernate.dialect.HSQLDialect Reporter: Ondrej Medek HQL UPDATE: UPDATE Lesson e SET e.state = 'N' WHERE EXISTS (SELECT 1 FROM LessonOrder lso WHERE lso.lesson = e) produces wrong SQL: update LESSON set lsn_state='N' where exists (select 1 from LESSON_ORDER lessonorde1_ where lessonorde1_.lsn_id=lsn_id) since in the database exists columns if the same name: LESSON.lsn_id and LESSON_ORDER.lsn_id. The problem is, that Hibernate omits the alias "e" in the SQL. When I make a little different query: UPDATE Lesson e SET e.state = 'N' WHERE EXISTS (SELECT 1 FROM LessonOrder lso WHERE lso.lesson.id = e.id) then the resulting SQL is right: update LESSON set lsn_state='N' where exists (select 1 from LESSON_ORDER lessonorde1_ where lessonorde1_.lsn_id=LESSON.lsn_id) However, I think the Hibernate should not omit the alias "e" in either case. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5146) org.hibernate.util.IdentitySet.iterator() return Map.Entry instances instead of actual elements

by Nicklas Nordborg (JIRA)

org.hibernate.util.IdentitySet.iterator() return Map.Entry instances instead of actual elements ----------------------------------------------------------------------------------------------- Key: HHH-5146 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5146 Project: Hibernate Core Issue Type: Bug Components: core Reporter: Nicklas Nordborg Priority: Trivial Attachments: patch.txt By accident I used the IdentitySet implementation in my code and got ClassCastException:s when iterating over it. It turns out that the iterator() method returns Map.entrySet().iterator() instead of Map.keySet().iterator(). There is also a similar problem with the toArray() methods. I provide a patch. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-680) Clarify the documentation around date bridges and that they are using DateTools

by Hardy Ferentschik (JIRA)

Clarify the documentation around date bridges and that they are using DateTools ------------------------------------------------------------------------------- Key: HSEARCH-680 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-680 Project: Hibernate Search Issue Type: Task Components: documentation Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Fix For: 3.4.0 See also https://forum.hibernate.org/viewtopic.php?f=9&t=1009427 Maybe also time to implement some of the todos in {{DateBridge}} * allow pattern like yyyyMMdd? * allow base timezone? -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3404) Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2)

by Geoffrey De Smet (JIRA)

Regular expressions (regex) boolean operator in HQL's where clause: rlike in mysql, regexp_match in informix, ... (regression from hibernate2) ---------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3404 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3404 Project: Hibernate3 Issue Type: New Feature Components: query-hql Affects Versions: 3.2.6 Reporter: Geoffrey De Smet Hibernate 2 supported the rlike boolean operator (at least for mysql): HB-1034. Hibernate3 currently doesn't. It turns out that most mainstream databases support regular expression patterns (independently from normal like patterns). Mysql: rlike where a.serial rlike '\d*' Informix: regexp_match() where regexp_match(a.serial, '\d*') Oracle: REGEXP_LIKE where REGEXP_LIKE(a.serial, '\d*') There have been several forum posts asking about this feature for hibernate3 btw: http://forum.hibernate.org/viewtopic.php?p=2391395 http://forum.hibernate.org/viewtopic.php?p=2375634 etc -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

6
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3887) Envers hbm xml based configuration

by Helmut Pasch (JIRA)

Envers hbm xml based configuration ---------------------------------- Key: HHH-3887 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3887 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.5 Environment: Hibernate: All Hibernate Versions including Envers as subproject Our Project: Hibernate 3.3.1, Spring 2.5.6, Spring DM 1.2.0, Swing, GWT, .... Reporter: Helmut Pasch Currently the tool library Envers can only be configured / mapped to java POJOs by annotations. We would appreciate if this mapping could be done by hbm xml files. Using this approach the POJO won't be bound to Envers annotations. They simply would be left as POJOs instead of transformed to JPA like Entity Beans. We use POJOs to directly serialize them to a client tier, e.g. a Swing or GWT client tier. If our POJOs have to rely on Envers annotations similar like JPA annotations we see only two options objects may leave the server tier. First by a copy to an annotation less value object, which is consuming performance and resources. Second by coping / using Envers / Hibernate libraries for reference purposes on the client tier. Both solutions are not very attractive compared to the very well working hbm xml approach Hibernate core ORM functionality provides us. It is our intention to reduce / eliminate in client server communication model transformations like coping objects or transforming them to other formats like XML, e.g. like web services does. The easiest way would be to just serialize the Java POJO objects. But never then less the client should only depend (logically) on the server API. It is not intended to rely on a specific server implementation. -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5525) Convert Getting Started Guide to use DocBook 5

by Steve Ebersole (JIRA)

Convert Getting Started Guide to use DocBook 5 ---------------------------------------------- Key: HHH-5525 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5525 Project: Hibernate Core Issue Type: Task Components: documentation Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6.0.CR1 This may require work on jDocBook to support, not sure. For sure we will need a docbook 5 bundle for maven respoitory -- 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.... - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 2 months

2
13
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2011