[Hibernate-JIRA] Commented: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list
by Igor Vaynberg (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ]
Igor Vaynberg commented on HHH-1268:
------------------------------------
any idea on when this will be fixed? it has been opened for almost three years...
> Unidirection OneToMany causes duplicate key entry violation when removing from list
> -----------------------------------------------------------------------------------
>
> Key: HHH-1268
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1
> Environment: 3.1 final
> MySql 4.1.14 using MYISAM tables
> Reporter: Rex Madden
> Assignee: Gail Badner
> Fix For: 3.2.x, 3.3.x
>
> Attachments: src.zip
>
>
> Simple OneToMany parent/child relationship using the default table structure (2 tables and a join table)
> Add 3 children to the parent. Flush. Remove the first child. Flush throws error:
> Exception in thread "main" org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update
> at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:69)
> at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:202)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:230)
> at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:143)
> at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:296)
> at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27)
> at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:980)
> at UnidirectionalOneToManyRemoveFromListBug.main(UnidirectionalOneToManyRemoveFromListBug.java:27)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at com.intellij.rt.execution.application.AppMain.main(AppMain.java:86)
> Caused by: java.sql.BatchUpdateException: Duplicate key or integrity constraint violation, message from server: "Duplicate entry '5' for key 2"
> at com.mysql.jdbc.PreparedStatement.executeBatch(PreparedStatement.java:1461)
> at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:58)
> at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:195)
> ... 11 more
> The problem is that there is a unique key on the relationship table that gets violated. The session removes the last row in the relationship table, then attempts to rewrite the child_id's. It fails since there is a uniqueness constraint on that column.
--
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, 5 months
[Hibernate-JIRA] Closed: (HHH-1969) Table aliases constructed incorrectly from HQL when JOIN is used when selecting multiple objects
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1969?page=c... ]
Steve Ebersole closed HHH-1969.
-------------------------------
Resolution: Duplicate
> Table aliases constructed incorrectly from HQL when JOIN is used when selecting multiple objects
> ------------------------------------------------------------------------------------------------
>
> Key: HHH-1969
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1969
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-hql
> Affects Versions: 3.2.0.cr3
> Environment: MS SQL Server 2000, JDK1.5, Hibernate 3.2cr3
> Reporter: Ryan Norris
> Priority: Critical
>
> When constructing a query to retrieve a "cross" join (cartesian product) of multiple objects and a JOIN is used, the table aliases for the cartesian objects are misplaced during query translation:
> Example:
> SELECT
> p, c, u
> FROM
> Practice p,
> Publication c,
> UserGroup u
> JOIN
> p.locations AS l
> WITH l.practice = p
> Results in a translated SQL query of:
> select
> practice0_.practice_id as practice1_54_0_,
> publicatio1_.publication_id as publicat1_56_1_,
> usergroup2_.usergroup_id as usergroup1_59_2_,
> practice0_.brand_id as brand4_54_0_,
> practice0_.practice_nm as practice2_54_0_,
> practice0_.active_flg as active3_54_0_,
> publicatio1_.admin_flg as admin2_56_1_,
> publicatio1_.practice_id as practice6_56_1_,
> publicatio1_.usergroup_id as usergroup7_56_1_,
> publicatio1_.inbox_user_id as inbox8_56_1_,
> publicatio1_.publication_nm as publicat3_56_1_,
> publicatio1_.location_id as location9_56_1_,
> publicatio1_.visible_flg as visible4_56_1_,
> publicatio1_.active_flg as active5_56_1_,
> usergroup2_.usergroup_nm as usergroup2_59_2_,
> usergroup2_.icon as icon59_2_
> from
> dbo.practice practice0_
> inner join
> dbo.location locations3_
> on practice0_.practice_id=locations3_.practice_id
> and (
> locations3_.practice_id=practice0_.practice_id
> ),
> dbo.publication publicatio1_,
> dbo.usergroup usergroup2_
> Notice how the table aliases for publication and usergroup are incorrectly placed.
--
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, 5 months
[Hibernate-JIRA] Closed: (HHH-1603) ANSI cross join - SQL Server 2000
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1603?page=c... ]
Steve Ebersole closed HHH-1603.
-------------------------------
Resolution: Duplicate
> ANSI cross join - SQL Server 2000
> ---------------------------------
>
> Key: HHH-1603
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1603
> Project: Hibernate Core
> Issue Type: Bug
> Components: query-hql
> Affects Versions: 3.1.2
> Environment: SQL Server 2000 and org.hibernate.dialect.SQLServerDialect
> Reporter: amit bhayani
> Attachments: ANSIJoinFragment.java, ANSIJoinFragment.java.patch
>
>
> There is a scope issue with cross joins generated by hibernate for SQL Server 2000. Below shown two cross join examples, the first is analogous to a cross join generated by hibernate which uses non-standard syntax, and the the second uses ANSI syntax. org.hibernate.dialect.SQLServerDialect uses org.hibernate.sql.ANSIJoinFragment to generate the cross join. Shouldn't ANSIJoinFragment use ANSI syntax? (" cross join " vs. ", "). See the attached suggested patch to Hibernate 3.1.2.
> -- Non-standard cross join syntax (doesn't work)
> -- Server: Msg 107, Level 16, State 2, Line 1
> -- The column prefix 'pt' does not match with a table name or alias name used in the query.
> select vpp.*, pt.*
> from xVS_PriceType pt, xVS_Product vp
> left join xVS_Price vpp on vpp.product_id = vp.id and vpp.priceType_id = pt.id
> -- ANSI cross join syntax (works)
> select vpp.*, pt.*
> from xVS_Product vp cross join xVS_PriceType pt
> left join xVS_Price vpp on vpp.product_id = vp.id and vpp.priceType_id = pt.id
--
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, 5 months
[Hibernate-JIRA] Commented: (HHH-1480) JOIN precendence rules per SQL-99
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480?page=c... ]
Steve Ebersole commented on HHH-1480:
-------------------------------------
I am only aware of this occurring from HQL queries. If users are seeing this occurs from other execution paths, the solution I am about to lay down will not effect them.
Basically, in the query parser there is a point at which we are trying to determine where to place commas between table references. All we need to change to properly support this is to replace the comma ( ", " ) with an explicit cross join ( " cross join " ). The difficulty there is how to handle databases which do not handle from clause joins (and do we care).
> JOIN precendence rules per SQL-99
> ---------------------------------
>
> Key: HHH-1480
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480
> Project: Hibernate Core
> Issue Type: New Feature
> Components: query-hql
> Affects Versions: 3.1.2
> Reporter: trebor iksrazal
> Assignee: Steve Ebersole
> Fix For: 3.2.x, 3.3.x, 3.4
>
>
> In SQL-92 joins performed in the where clause (comma operator in from clause) and joins performed in the from clause (join keyword) had the same precedence. SQL-99 clarified this such that the from clause joins had higher precedence.
> Hibernate currently treats these as having the same precedence.
> A good explanation comes from the MySQL docs ( http://dev.mysql.com/doc/refman/5.0/en/join.html ) :
> #
> Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.
> Example:
> CREATE TABLE t1 (i1 INT, j1 INT);
> CREATE TABLE t2 (i2 INT, j2 INT);
> CREATE TABLE t3 (i3 INT, j3 INT);
> INSERT INTO t1 VALUES(1,1);
> INSERT INTO t2 VALUES(1,1);
> INSERT INTO t3 VALUES(1,1);
> SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
> Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:
> SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
> Alternatively, avoid the use of the comma operator and use JOIN instead:
> SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
> This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma 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, 5 months
[Hibernate-JIRA] Updated: (HHH-1480) JOIN precendence rules per SQL-99
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480?page=c... ]
Steve Ebersole updated HHH-1480:
--------------------------------
Description:
In SQL-92 joins performed in the where clause (comma operator in from clause) and joins performed in the from clause (join keyword) had the same precedence. SQL-99 clarified this such that the from clause joins had higher precedence.
Hibernate currently treats these as having the same precedence.
A good explanation comes from the MySQL docs ( http://dev.mysql.com/doc/refman/5.0/en/join.html ) :
#
Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.
Example:
CREATE TABLE t1 (i1 INT, j1 INT);
CREATE TABLE t2 (i2 INT, j2 INT);
CREATE TABLE t3 (i3 INT, j3 INT);
INSERT INTO t1 VALUES(1,1);
INSERT INTO t2 VALUES(1,1);
INSERT INTO t3 VALUES(1,1);
SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:
SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
Alternatively, avoid the use of the comma operator and use JOIN instead:
SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma operator.
was:
http://dev.mysql.com/doc/refman/5.0/en/join.html
"Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard. The following list provides more detail about several effects of the 5.0.12 change in join processing. The term "previously" means "prior to MySQL 5.0.12."
Using 5.0.18 and hibernate 3.1.2, hibernate is not producing the correct join syntax for the latest versions of mysql.
For example:
FROM tableA AS A, tableB AS B INNER JOIN tableC AS C ON A.field1 =
C.field2
The above fails, because the B JOIN C is evaluated before the A alias has
been created.
The solution is to use parentheses to force an order of evaluation:
FROM (tableA AS A, tableB AS B) INNER JOIN tableC AS C ON A.field1 =
C.field2
Summary: JOIN precendence rules per SQL-99 (was: Support new MySQL 5.0.12 join syntax)
> JOIN precendence rules per SQL-99
> ---------------------------------
>
> Key: HHH-1480
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480
> Project: Hibernate Core
> Issue Type: New Feature
> Components: query-hql
> Affects Versions: 3.1.2
> Reporter: trebor iksrazal
> Assignee: Steve Ebersole
> Fix For: 3.2.x, 3.3.x, 3.4
>
>
> In SQL-92 joins performed in the where clause (comma operator in from clause) and joins performed in the from clause (join keyword) had the same precedence. SQL-99 clarified this such that the from clause joins had higher precedence.
> Hibernate currently treats these as having the same precedence.
> A good explanation comes from the MySQL docs ( http://dev.mysql.com/doc/refman/5.0/en/join.html ) :
> #
> Previously, the comma operator (,) and JOIN both had the same precedence, so the join expression t1, t2 JOIN t3 was interpreted as ((t1, t2) JOIN t3). Now JOIN has higher precedence, so the expression is interpreted as (t1, (t2 JOIN t3)). This change affects statements that use an ON clause, because that clause can refer only to columns in the operands of the join, and the change in precedence changes interpretation of what those operands are.
> Example:
> CREATE TABLE t1 (i1 INT, j1 INT);
> CREATE TABLE t2 (i2 INT, j2 INT);
> CREATE TABLE t3 (i3 INT, j3 INT);
> INSERT INTO t1 VALUES(1,1);
> INSERT INTO t2 VALUES(1,1);
> INSERT INTO t3 VALUES(1,1);
> SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
> Previously, the SELECT was legal due to the implicit grouping of t1,t2 as (t1,t2). Now the JOIN takes precedence, so the operands for the ON clause are t2 and t3. Because t1.i1 is not a column in either of the operands, the result is an Unknown column 't1.i1' in 'on clause' error. To allow the join to be processed, group the first two tables explicitly with parentheses so that the operands for the ON clause are (t1,t2) and t3:
> SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
> Alternatively, avoid the use of the comma operator and use JOIN instead:
> SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);
> This change also applies to statements that mix the comma operator with INNER JOIN, CROSS JOIN, LEFT JOIN, and RIGHT JOIN, all of which now have higher precedence than the comma 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, 5 months
[Hibernate-JIRA] Updated: (HHH-1480) Support new MySQL 5.0.12 join syntax
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480?page=c... ]
Steve Ebersole updated HHH-1480:
--------------------------------
Assignee: Steve Ebersole
Fix Version/s: 3.4
3.3.x
3.2.x
Requires Release Note: [Affirmative]
Component/s: (was: query-sql)
query-hql
> Support new MySQL 5.0.12 join syntax
> ------------------------------------
>
> Key: HHH-1480
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1480
> Project: Hibernate Core
> Issue Type: New Feature
> Components: query-hql
> Affects Versions: 3.1.2
> Reporter: trebor iksrazal
> Assignee: Steve Ebersole
> Fix For: 3.2.x, 3.3.x, 3.4
>
>
> http://dev.mysql.com/doc/refman/5.0/en/join.html
> "Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard. The following list provides more detail about several effects of the 5.0.12 change in join processing. The term "previously" means "prior to MySQL 5.0.12."
> Using 5.0.18 and hibernate 3.1.2, hibernate is not producing the correct join syntax for the latest versions of mysql.
> For example:
> FROM tableA AS A, tableB AS B INNER JOIN tableC AS C ON A.field1 =
> C.field2
> The above fails, because the B JOIN C is evaluated before the A alias has
> been created.
> The solution is to use parentheses to force an order of evaluation:
> FROM (tableA AS A, tableB AS B) INNER JOIN tableC AS C ON A.field1 =
> C.field2
--
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, 5 months