[Hibernate-JIRA] Created: (HHH-2558) Allow batching inserts for multi-table entities
by Steve Ebersole (JIRA)
Allow batching inserts for multi-table entities
-----------------------------------------------
Key: HHH-2558
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2558
Project: Hibernate3
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
<joined-subclass/> as well as entity's containing <join/> mappings currently cannot participating in JDBC batching. The reaons being that the actions (i.e. Executables) perform the insert or update in an atomic fashion through the persisters; the persisters perform the multiple statements.
One possible approach for solving would be to have the persisters somehow expose the fact that inserts or updates effect multiple tables and to have the actions drive the executions of those statements.
Another possible approach would be to change how Batcher works. Currently, batcher is capable of tracking a single jdbc batch statement, which it does by string comparison of the sql. So a new sql command is seen as the impetus to start a new batch. So we could change this to make batch a logical concept such that the "grouping" is actually at a higher level : like say "[command]:[entity-name](:[id])". Then we could have batches keyed by "update:Customer:1" rather than "update CUSTOMER set ...". Would need to be very careful in the case of dynamic-insert and dynamic-update...
This is a follow-on to HHH-1
--
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
17 years, 6 months
[Hibernate-JIRA] Commented: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by John (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
John commented on HHH-952:
--------------------------
Maybe something changed in the related logic - I didn't knowingly get tricky with the constructor order. Mostly I took code from other places in Hibernate that were doing the right thing and cobbled together something that works. The criteria code is pretty complex and this was my first use of Hibernate, and being in the middle of a project I only had time enough to spend solving my problem. I'm glad it did and just hoped this patch would get into the eyes of someone with a lot more knowledge of it than me. Thanks everyone for keeping the patch updated with newer Hibernate versions. I haven't had time and our app isn't being updated, so I appreciate everyone keeping it up.
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Priority: Critical
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
17 years, 7 months
[Hibernate-JIRA] Commented: (HHH-1524) Error on left outer join with Oracle Dialect: ORA-00936: missing expression
by Konstantin Skabeev (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524?page=c... ]
Konstantin Skabeev commented on HHH-1524:
-----------------------------------------
Milosz, that's exactly the problem: Hibernate inserts outer joins where it really shouldn't, that is in the conditions with OR and IN operators. This results in an SQL Grammar errors. Ideally, the whole condition should be parsed and (+) inserted only where it's safe, where there are no OR or IN operators. Certainly, this would require writing pretty sophisticated parser to take care of all the cases I described in my previous comment.
> Error on left outer join with Oracle Dialect: ORA-00936: missing expression
> ---------------------------------------------------------------------------
>
> Key: HHH-1524
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524
> Project: Hibernate3
> Issue Type: Bug
> Components: query-sql
> Affects Versions: 3.1.2
> Environment: Oracle 8.1.7, Hibernate 3.1.2
> Reporter: Marcelo Oliveira
> Priority: Critical
> Attachments: HHH-1524.patch, ORA-00936.zip, SUP-3701.zip
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> With this HQL:
> from Company comp
> left outer join comp.employees empl
> with empl.birthday > :date
> Produce following SQL:
> select
> company0_.id as id0_0_,
> employees1_.id as id1_1_,
> company0_.companyName as companyN2_0_0_,
> employees1_.name as name1_1_,
> employees1_.birthday as birthday1_1_,
> employees1_.companyId as companyId1_1_
> from
> TB_COMPANY_TEMP company0_,
> TB_EMPLOYEE_TEMP employees1_
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>(+)=?)
> When it is run, the stacktrace is:
> org.hibernate.exception.SQLGrammarException: could not execute query
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:65)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2148)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
> at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
> at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1129)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at mytest.OuterJoinTest.main(OuterJoinTest.java:28)
> Caused by: java.sql.SQLException: ORA-00936: missing expression
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1870)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:314)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2145)
> ... 8 more
> The correct where clause should be :
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>=?)
> This error don't occur with MySQLDialect or SQLServerDialect. Probably it considers >= as two operators instead of a single operator.
--
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
17 years, 7 months
[Hibernate-JIRA] Commented: (HHH-1524) Error on left outer join with Oracle Dialect: ORA-00936: missing expression
by Milosz Tylenda (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524?page=c... ]
Milosz Tylenda commented on HHH-1524:
-------------------------------------
Konstantin, sure, my patch is only a kludge but isn't it that Oracle 8 prohibits outer joins with OR and IN operators? From their docs:
# A condition containing the (+) operator cannot be combined with another condition using the OR logical operator.
# A condition cannot use the IN comparison operator to compare a column marked with the (+) operator with an expression.
> Error on left outer join with Oracle Dialect: ORA-00936: missing expression
> ---------------------------------------------------------------------------
>
> Key: HHH-1524
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1524
> Project: Hibernate3
> Issue Type: Bug
> Components: query-sql
> Affects Versions: 3.1.2
> Environment: Oracle 8.1.7, Hibernate 3.1.2
> Reporter: Marcelo Oliveira
> Priority: Critical
> Attachments: HHH-1524.patch, ORA-00936.zip, SUP-3701.zip
>
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> With this HQL:
> from Company comp
> left outer join comp.employees empl
> with empl.birthday > :date
> Produce following SQL:
> select
> company0_.id as id0_0_,
> employees1_.id as id1_1_,
> company0_.companyName as companyN2_0_0_,
> employees1_.name as name1_1_,
> employees1_.birthday as birthday1_1_,
> employees1_.companyId as companyId1_1_
> from
> TB_COMPANY_TEMP company0_,
> TB_EMPLOYEE_TEMP employees1_
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>(+)=?)
> When it is run, the stacktrace is:
> org.hibernate.exception.SQLGrammarException: could not execute query
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:65)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.loader.Loader.doList(Loader.java:2148)
> at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2029)
> at org.hibernate.loader.Loader.list(Loader.java:2024)
> at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:375)
> at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:308)
> at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:153)
> at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1129)
> at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
> at mytest.OuterJoinTest.main(OuterJoinTest.java:28)
> Caused by: java.sql.SQLException: ORA-00936: missing expression
> at oracle.jdbc.dbaccess.DBError.throwSqlException(DBError.java:168)
> at oracle.jdbc.ttc7.TTIoer.processError(TTIoer.java:208)
> at oracle.jdbc.ttc7.Oall7.receive(Oall7.java:543)
> at oracle.jdbc.ttc7.TTC7Protocol.doOall7(TTC7Protocol.java:1405)
> at oracle.jdbc.ttc7.TTC7Protocol.parseExecuteDescribe(TTC7Protocol.java:643)
> at oracle.jdbc.driver.OracleStatement.doExecuteQuery(OracleStatement.java:1674)
> at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1870)
> at oracle.jdbc.driver.OraclePreparedStatement.executeUpdate(OraclePreparedStatement.java:363)
> at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:314)
> at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:139)
> at org.hibernate.loader.Loader.getResultSet(Loader.java:1669)
> at org.hibernate.loader.Loader.doQuery(Loader.java:662)
> at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
> at org.hibernate.loader.Loader.doList(Loader.java:2145)
> ... 8 more
> The correct where clause should be :
> where
> company0_.id=employees1_.companyId(+)
> and (employees1_.birthday(+)>=?)
> This error don't occur with MySQLDialect or SQLServerDialect. Probably it considers >= as two operators instead of a single operator.
--
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
17 years, 7 months
[Hibernate-JIRA] Commented: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by Jon Seymour (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
Jon Seymour commented on HHH-952:
---------------------------------
I've attached a variant (subquery-patch-3.2.4.SP1.txt) of (subquery-patch-313.txt) which addresses the NullPointerException that I reported with a previous post.
It seems that earlier versions of the patch were relying on constructor and initializer behaviour that is not guaranteed by the Java Language Specification (in particular, the order in which subclass instance variables and inner class references are initialized w.r.t. to the execution of base class constructors). This patch addresses this by removing the use of the inner class and adding an explicit alias argument to the constructors in the hierarchy of CriteriaJoinWalker.
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Priority: Critical
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
17 years, 7 months
[Hibernate-JIRA] Updated: (HHH-952) Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
by Jon Seymour (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-952?page=co... ]
Jon Seymour updated HHH-952:
----------------------------
Attachment: subquery-patch-3.2.4.SP1.txt
This patch extends subquery-patch-313.txt and has been tested with hibernate-3.2.4.SP1 running under IBM RAD and IBM WebSphere 6.
This fix corrects a problem with the previous patch in that it does not rely on unspecified or undocumented constructor/initialization behaviour but instead is safe assuming only that the JLS is implemented correctly.
> Patch to allow subqueries with joins using Criteria API and Subqueries with DetachedCriteria
> --------------------------------------------------------------------------------------------
>
> Key: HHH-952
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-952
> Project: Hibernate3
> Issue Type: Patch
> Components: core
> Affects Versions: 3.1 beta 1, 3.1 beta 2
> Environment: 3.1beta1 with MS SQL 2000 via jTDS
> Reporter: John
> Priority: Critical
> Attachments: subquery-patch-3.2.4.SP1.txt, subquery-patch-311.txt, subquery-patch-313.txt, subquery-patch-31beta3.txt, subquery-patch.txt, subquery-patch.txt, SubqueryExpression.java
>
>
> The existing code in SubqueryExpression.java constructed a select statement but did not have any provisions for creating joins. Therefore, it was not possible using the criteria API to create an exists subselect that had a join, even though running the source DetachedCriteria alone works perfectly.
> For example, if this is the goal:
> select * from foo f
> where exists (select id from bar b join other o on b.o_id = o.id where o.prop = '123' and b.foo_id = f.id)
> One might try something like this:
> Criteria crit = session.createCriteria(Foo.class, fooAlias);
> DetachedCriteria barCrit = DetachedCriteria.forClass(Bar.class, barAlias);
> DetachedCriteria otherCrit = barCrit.createCriteria(Bar.OTHER_JOIN);
> otherCrit.add( Restrictions.eq(Other.PROP, "123") );
> barCrit.add( Restrictions.eqProperty( -- props to join to foo here --) );
> barCrit.setProjection( Projections.id() );
> crit.add( Subqueries.exists(barCrit) );
> However, the existing code generates something like the following, which gets an error with an unknown alias 'o':
> select * from foo f
> where exists (select id from bar b where o.prop = '123' and b.foo_id = f.id)
> This is also described here (at the end): http://forum.hibernate.org/viewtopic.php?t=942488
> The patch to SubqueryExpression.java fixes this to included the joins necessary for the filtering. This code was modeled (copied) off of code from CriteriaLoader. For me this works perfectly, but I don't understand the internals of this stuff enough to say how robust it is. Also included is a patch to the test case to enable testing of this, which was present but commented out. I did not change the contents of the test, which currently only attempts a joined subquery. This used to fail with an error, but now it works. The test does not check the results at all. (Inconsequential to the patch - Enrollment has two Ls.)
> -----side notes
> The patch file also has two other patches. The first increases the delay in BulkManipulationTest because I was getting inconsistent test results. I think that the precision on the version timestamp is not enough for 300 milliseconds delay to be enough to guarantee the test results. Also, in build.xml, there was a line that was meant to exclude the performance tests, but there was no **/*, on *, so they actually were not excluded. I changed this so the tests would complete in a reasonable amount of time. However, there is one other issue with testing that I worked around manually. After each test run, two databases (Users and Email) were left in the database. If I did not manually delete these then the number of failures on the next test run was different. This was really confusing until I figured it out because I was trying to make sure all the other testcases still passed with my patch, but even without the patch I was getting different results.
--
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
17 years, 7 months