June 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1724) Critieria needs to be aligned with new aggreation type rules

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724?page=c... ] Steve Ebersole commented on HHH-1724: ------------------------------------- 3.5 would represent a good time to do this, both because it is a major rev and because we will be supporting the new JPA criteria API in 3.5. I have to assume the JPA criteria API returns are expected to be aligned. Reopening more for discussion Max. Feel free to assign to me if you want... > Critieria needs to be aligned with new aggreation type rules > ------------------------------------------------------------ > > Key: HHH-1724 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > Priority: Blocker > Fix For: 3.5 > > > Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is..... > created as blocker to make sure we either document or fix it. -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1724) Critieria needs to be aligned with new aggreation type rules

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724?page=c... ] Steve Ebersole updated HHH-1724: -------------------------------- Fix Version/s: 3.5 > Critieria needs to be aligned with new aggreation type rules > ------------------------------------------------------------ > > Key: HHH-1724 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > Priority: Blocker > Fix For: 3.5 > > > Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is..... > created as blocker to make sure we either document or fix it. -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3497) Criteria row count return value in the type of Integer, not Long

by Yang Lifan (JIRA)

Criteria row count return value in the type of Integer, not Long ---------------------------------------------------------------- Key: HHH-3497 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3497 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: MySQL and Postgres Reporter: Yang Lifan I know the type of the return value of row count with HQL query is Long, to be compatible with JPA. But the Criteria is still return in the type of Integer, not in Long. So if there are a huge amount of data in the database, how can we get the right row count value with Criteria. ================================================= criteria.setProjection(Projections.rowCount()); Long result = Long.valueOf(criteria.uniqueResult().toString()); ================================================= I have to write like that to return the type of Long. But I know it is not real. -- 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

15 years, 7 months

4
3
0 / 0

[Hibernate-JIRA] Reopened: (HHH-1724) Critieria needs to be aligned with new aggreation type rules

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724?page=c... ] Steve Ebersole reopened HHH-1724: --------------------------------- > Critieria needs to be aligned with new aggreation type rules > ------------------------------------------------------------ > > Key: HHH-1724 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1724 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Max Rydahl Andersen > Assignee: Max Rydahl Andersen > Priority: Blocker > > Criteria does not ask the dialect about the type + it does not always seem to know what the underlying field type is..... > created as blocker to make sure we either document or fix it. -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-3941) Failed to open Hibernate Session due to could not register synchronization with JTA TransactionManager

by singaraiah dheekonda (JIRA)

Failed to open Hibernate Session due to could not register synchronization with JTA TransactionManager ------------------------------------------------------------------------------------------------------ Key: HHH-3941 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3941 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.0 final Environment: hibernate 3.0 Reporter: singaraiah dheekonda Priority: Critical Attachments: stdout.log Failed to open Hibernate Session due to could not register synchronization with JTA TransactionManager -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1012) Index not created by SchemaUpdate

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1012?page=c... ] Steve Ebersole updated HHH-1012: -------------------------------- Fix Version/s: (was: 3.2.7) 3.2.x > Index not created by SchemaUpdate > --------------------------------- > > Key: HHH-1012 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1012 > Project: Hibernate Core > Issue Type: New Feature > Components: metamodel > Affects Versions: 3.2.5 > Environment: Windows XP, MySQL/PostgreSQL > Reporter: Xavier Farret > Assignee: Steve Ebersole > Priority: Minor > Fix For: 3.2.x, 3.3.x, 3.5 > > Attachments: Indexes.patch > > > i'm using an hbm.xml as describe below and the 'hibernate.hbm2ddl.auto' is egal to update. > <class table="featurestat" name="....."> > <id name="id" type="long" column="idFeatureStat"> > <generator class="increment"/> > </id> > <properties name="fsUniqueValue" unique="true"> > .... > </properties> > <property name="frequency" .../> > <property name="idFatherFeature" index="FeatStatDocExtSectFeat" not-null="true" type="long" column="..."/> > .... > </class> > Indexes for pk or unique key are well created, but the index explicity named 'FeatStatDocExtSectFeat' is never created. If i put the property 'hibernate.hbm2ddl.auto' in the cfg.xml as 'create' the index is created. But in my case i have to set my property 'hibernate.hbm2ddl.auto' to update. -- 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1268) Unidirection OneToMany causes duplicate key entry violation when removing from list

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1268?page=c... ] Steve Ebersole updated HHH-1268: -------------------------------- Fix Version/s: (was: 3.2.7) 3.2.x > 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Updated: (HHH-1496) A new dialect is required for MySQL NDB clustered table types

by Steve Ebersole (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496?page=c... ] Steve Ebersole updated HHH-1496: -------------------------------- Fix Version/s: (was: 3.2.7) 3.2.x > A new dialect is required for MySQL NDB clustered table types > ------------------------------------------------------------- > > Key: HHH-1496 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1496 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1.2 > Reporter: Darran Lofthouse > Assignee: Juraci Paixao Krohling > Fix For: 3.2.x, 3.3.x, 3.5 > > Attachments: HHH-1496.diff > > > A new dialect is required for MySQL NDB clustered table types > http://dev.mysql.com/doc/refman/5.0/en/create-table.html > Either ENGINE=NDB or ENGINE=NDBCLUSTER > Also FYI ENGINE is the prefered way of specifying the type over TYPE so MySQLMyISAMDialect and MySQLInnoDBDialect could also be updated to use ENGINE -- 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

15 years, 7 months

1
0
0 / 0

[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: -------------------------------- Fix Version/s: (was: 3.2.7) 3.2.x > 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.5 > > > 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

15 years, 7 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1483) MySQL5: No Dialect mapping for JDBC type: -1

by Gail Badner (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1483?page=c... ] Gail Badner commented on HHH-1483: ---------------------------------- Hi Lars, We do need a test case that reproduces the issue so we can see that the issue actually got resolved by a fix. Also, if the issue does not appear to be dialect-specific, then the test case helps us confirm that is true. I don't think that: registerHibernateType( Types.LONGVARBINARY, Hibernate.BLOB.getName() ); will work for Sybase. Instead, I think it should be registerHibernateType( Types.LONGVARBINARY, Hibernate.IMAGE.getName() ); A test case really would help get this fixed. Gail > MySQL5: No Dialect mapping for JDBC type: -1 > -------------------------------------------- > > Key: HHH-1483 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1483 > Project: Hibernate Core > Issue Type: Bug > Components: core > Affects Versions: 3.1.2 > Environment: MySQL 5.0.18-nt > Reporter: Sergey Vladimirov > Priority: Minor > Attachments: hhh-1483-patch.txt > > > MySQL5: No Dialect mapping for JDBC type: -1 > SELECT answpos,answer FROM votes_answers WHERE question=? ORDER BY answpos > mysql> describe votes_answers; > +----------+---------+------+-----+---------+-------+ > | Field | Type | Null | Key | Default | Extra | > +----------+---------+------+-----+---------+-------+ > | question | int(11) | NO | MUL | | | > | answpos | int(11) | NO | | | | > | answer | text | YES | | NULL | | > +----------+---------+------+-----+---------+-------+ > mysql> describe temp; > +---------+---------+------+-----+---------+-------+ > | Field | Type | Null | Key | Default | Extra | > +---------+---------+------+-----+---------+-------+ > | answpos | int(11) | NO | | 0 | | > | answer | text | YES | | NULL | | > +---------+---------+------+-----+---------+-------+ > Please, let me know what to add to MySQL5Dialect :) > Will it be ok to add? : > registerColumnType( Types.LONGVARCHAR, "text" ); -- 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

15 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2009