February 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (ANN-544) @SqlDeleteAll wrt to Collections

by Thomas Kubicek (JIRA)

@SqlDeleteAll wrt to Collections -------------------------------- Key: ANN-544 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-544 Project: Hibernate Annotations Type: Bug Components: binder Versions: 3.2.1 Environment: 3.2.1GA - MSSQL ( but irrelivant ) Reporter: Thomas Kubicek Hibernate Annotations for @SqlDeleteAll when applied to Collections CollectionBinder is not assigning the sql statement to the "setCustomSQLDeleteAll" but rather the "setCustomSQLDelete" CollectionBinder.java line 361-370. this prevents the execution of col.clear() method on the collection where all elements are removed. -- 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, 3 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2433) Use of an id together with a natural-id results in an ArraIndexOutOfBoundsException

by Danny Bols (JIRA)

Use of an id together with a natural-id results in an ArraIndexOutOfBoundsException ------------------------------------------------------------------------------------ Key: HHH-2433 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2433 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: MySql, Cocoon, WindowsXp Reporter: Danny Bols Attachments: hb-issue.txt Use of a natural-id in combination with a generated id results in an ArrayOutOfBoundsException. The table in the database has 2 unique keys, a natural-id and an internal id (UUID). A record is loaded in a separate transaction and send to a user form. When the user hits the save button the changes are committed in a new transaction. If this transaction doesn't contain a new load of the record the commit will result in an ArrayIndexOutOfBoundsException. If we leave out the natural-id definition in the config file we don't get an exception. See attachement for details. -- Danny -- 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, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2070) Improvement for DialectFactory

by Martin Renner (JIRA)

Improvement for DialectFactory ------------------------------ Key: HHH-2070 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2070 Project: Hibernate3 Type: Patch Components: core Versions: 3.2.0.cr4 Reporter: Martin Renner Attachments: DialectFactory.patch I would like to have more entries for autodetecting DB2 dialects. According to HHH-1467 I created a patch. At the moment, DialectFactory knows just "DB2/NT". We are currently using DB2Dialect for "DB2/6000" and "DB2/LINUX", but we would like to have Hibernate autodetect these dialects. So the patch simply adds two new lines to DialectFactory. It would be really helpful for us, if this patch would make it into 3.1.x and 3.2.x. The patch works for 3.1.3 and 3.2.0cr4. -- 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, 3 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2297) invalid id type error message doesn't report which entity

by Kelly Campbell (JIRA)

invalid id type error message doesn't report which entity --------------------------------------------------------- Key: HHH-2297 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2297 Project: Hibernate3 Type: Patch Components: metamodel Versions: 3.2.0.ga Reporter: Kelly Campbell Priority: Minor Attachments: hibernate-id-type.patch The error message given here makes it very hard to determine what entity has the problem. Simple patch is attached. java.lang.UnsupportedOperationException: not a valid id type at org.hibernate.type.CharacterType.getDefaultValue(CharacterType.java:20) at org.hibernate.engine.UnsavedValueFactory.getUnsavedIdentifierValue(UnsavedValueFactory.java:48) at org.hibernate.tuple.PropertyFactory.buildIdentifierProperty(PropertyFactory.java:44) at org.hibernate.tuple.EntityMetamodel.(EntityMetamodel.java:114) at org.hibernate.persister.entity.AbstractEntityPersister.(AbstractEntityPersister.java:418) at org.hibernate.persister.entity.SingleTableEntityPersister.(SingleTableEntityPersister.java:108) at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55) at org.hibernate.impl.SessionFactoryImpl.(SessionFactoryImpl.java:223) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1213) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:631) at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:760) at org.hibernate.ejb.Ejb3Configuration.createFactory(Ejb3Configuration.java:151) at org.hibernate.ejb.Ejb3Configuration.createEntityManagerFactory(Ejb3Configuration.java:205) -- 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, 3 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2261) Setting hibernate.hbm2ddl.auto=validate causes problems on mySQL with numeric fields

by Christian Sprajc (JIRA)

Setting hibernate.hbm2ddl.auto=validate causes problems on mySQL with numeric fields ------------------------------------------------------------------------------------ Key: HHH-2261 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2261 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Reporter: Christian Sprajc Hello, We got a Problem when using the following setup: 1) JBoss 4.0.4A with Hibernate 3.2.0 / mySQl 4.x AND 5.x 2) Set hibernate.hbm2ddl.auto=validate 3) Using a usertype which uses the SQL type: Types.NUMERIC When deploying our application I got the following error: 12:43:21,985 INFO [TableMetadata] columns: [paymenttype, amount, oid, remarks, currency, ae_date] 12:43:21,985 WARN [ServiceController] Problem starting service persistence.units:jar=com.riege.pogo_0.1.4.jar,unitName=PogoEntityManager org.hibernate.HibernateException: Wrong column type: amount, expected: numeric(19,2) at org.hibernate.mapping.Table.validateColumns(Table.java:251) at org.hibernate.cfg.Configuration.validateSchema(Configuration.java:1002) The Problem is: 1) When hibernate creates (e.g. hibernate.hbm2ddl.auto=update) through the columns in the mySQL database it creates it as "numeric(x,y)" field. 2) mySQL always converts "numeric(x,y)" to "decimal(x,y)". The metadata returns "decimal(x,y)" 3) When deploying with "hibernate.hbm2ddl.auto=validate" to error above is thrown. The problem is that hibernate expects a "numeric(x,y)" type but mysql returns a "decimal(x,y)" A workaround I'm now using is a fixed mySQL dialect which correctly handles Types.DECIMAL / "decimal(x,y)": public class FixedMySQLDialect extends org.hibernate.dialect.MySQLDialect { public FixedMySQLDialect() { super(); registerColumnType(Types.NUMERIC, "decimal(19, $l)"); registerColumnType(Types.DECIMAL, "decimal(19, $l)"); } } -- 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, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2089) ClobType.setToXMLNode: could not read XML from Clob

by Pietro Iglio (JIRA)

ClobType.setToXMLNode: could not read XML from Clob --------------------------------------------------- Key: HHH-2089 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2089 Project: Hibernate3 Type: Patch Components: core Versions: 3.2.0.cr4 Environment: Hib 3.2.0cr4, database: any Reporter: Pietro Iglio I get "org.hibernate.HibernateException: could not read XML from Clob" trying to retrieve a CLOB column as XML. I think I have found the reason of the bug in org.hibernate.type.ClobType: public void setToXMLNode(Node node, Object value, SessionFactoryImplementor factory) { ... node.setText( clob.getSubString(0, len) ); ... } According to the JDBC spec, the first character of Clob is at 1 position, so the correct line should be node.setText( clob.getSubString(1, len) ); -- 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, 3 months

4
5
0 / 0

[Hibernate-JIRA] Created: (HBX-730) SchemaExport with hibernate.hbm2ddl.auto does not create database schemas before it creates tables (fails with invalid schema name: on HSQLDB)

by Andrew Thompson (JIRA)

SchemaExport with hibernate.hbm2ddl.auto does not create database schemas before it creates tables (fails with invalid schema name: on HSQLDB) ----------------------------------------------------------------------------------------------------------------------------------------------- Key: HBX-730 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-730 Project: Hibernate Tools Type: Improvement Environment: Hibernate 3.0.5, HSQLDB 1.8 I've also read the code in the SchemaExport, Table and Configuration classes in 3.2rc3 and it looks like this hasn't been added in 3.1 or 3.2. Reporter: Andrew Thompson I'm writing a unit test that creates the database it will work with using hibernate.hbm2ddl.auto=create-drop. This all works fine, so long as I don't use schemas in my .hbm.xml: <class name="com.example.Foo" table="foo_table"> If I add a schema like this, then the database creation fails on HSQLDB 1.8: <class name="com.example.Foo" schema="bar" table="foo_table"> Unsuccessful: create table bar.foo_table ( ... column names ... ) hbm2ddl.SchemaExport - invalid schema name: BAR in statement [create table bar.foo_table] As far as I know there is no way to ask Hibernate to create the schema before it tries to create the tables. There is a forum thread here that shows I am not the only one with this issue: http://forum.hibernate.org/viewtopic.php?p=2316411&sid=c0cd248a87bfb8d684... As this is a unit test, precreating the schema in the test code is plausible, but not particularly attractive. -- 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, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2314) EntityUpdateAction does not do a deepCopy for loadedState, making change detection of Custom Type based on a Collection not working

by arnaud.roger＠gmail.com (JIRA)

EntityUpdateAction does not do a deepCopy for loadedState, making change detection of Custom Type based on a Collection not working ----------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2314 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2314 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.ga, 3.2.1 Environment: Hibernate 3.2.1.ga, SQLServer and Oracle 10 Reporter: arnaud.roger(a)gmail.com We have a User object with a roles HashSet<String> that is map with a CustomType to VARCHAR in the database using a comma separated format. When this Entity is manipulated through a long transaction hibernate does not detect that the Entity is dirty and does not flush the change to the database. This does not happen in Hibernate 3.1.1 After tracing through Hibernate I identified the bug. This is due to a change in the 3.2 branch in EntityUpdateAction http://fisheye.jboss.org/browse/~br=tag%3Av321/Hibernate/tags/v321/Hibern... The deepCopy is done only when hasUpdateGeneratedProperties() is true, which I is not for our User object. So the set is not deepCopy and the lastUpdated array got a reference to the the same set as the user object. Any modification is so done in the lastUpdated and the User entity, making the object non dirty. rollbacking to the 3.1.1 version of this file probably fix the issue. Regards Arnaud PS: I'd try to produce a simple test case in the next days -- 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, 3 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2113) Incorrect join ordering with filters and JOINED inheritance

by Barney Boisvert (JIRA)

Incorrect join ordering with filters and JOINED inheritance ----------------------------------------------------------- Key: HHH-2113 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2113 Project: Hibernate3 Type: Bug Versions: 3.2.0.cr4 Environment: Hibernate 3.2.0 CR4, MySQL 4.1.20 Reporter: Barney Boisvert I've a TextBlock object that extends AbstractContentObject (and has myriad other associations illustrated here, but irrelevant) and when doing a polymorphic query for all AbstractContentObjects Hibernate runs this SQL (note the line with the trailing asterisks): select textblockv0_.id as id21_5_, textblockv0_.createTimestamp as createTi2_21_5_, textblockv0_.hibernateVersionId as hibernat3_21_5_, textblockv0_.lastUpdateTimestamp as lastUpda4_21_5_, textblockv0_.lastVersionNumber as lastVers5_21_5_, textblockv0_.activeVersionId as activeVe6_21_5_, textblockv1_.id as id20_0_, textblockv1_.createTimestamp as createTi2_20_0_, textblockv1_.hibernateVersionId as hibernat3_20_0_, textblockv1_.lastUpdateTimestamp as lastUpda4_20_0_, textblockv1_.versionNumber as versionN5_20_0_, textblockv1_.frozen as frozen20_0_, textblockv1_.commitMessage as commitMe7_20_0_, textblockv1_.title as title20_0_, textblockv1_.summary as summary20_0_, textblockv1_.text as text20_0_, textblockv1_.versionHistoryId as version11_20_0_, textblockv2_.id as id21_1_, textblockv2_.createTimestamp as createTi2_21_1_, textblockv2_.hibernateVersionId as hibernat3_21_1_, textblockv2_.lastUpdateTimestamp as lastUpda4_21_1_, textblockv2_.lastVersionNumber as lastVers5_21_1_, textblockv2_.activeVersionId as activeVe6_21_1_, textblock3_.id as id18_2_, textblock3_1_.createTimestamp as createTi2_18_2_, textblock3_1_.hibernateVersionId as hibernat3_18_2_, textblock3_1_.siteId as siteId18_2_, textblock3_1_.orderCol as orderCol18_2_, textblock3_1_.folderId as folderId18_2_, textblock3_.versionHistoryId as versionH2_19_2_, site4_.id as id1_3_, site4_.createTimestamp as createTi2_1_3_, site4_.hibernateVersionId as hibernat3_1_3_, site4_.lastUpdateTimestamp as lastUpda4_1_3_, site4_.name as name1_3_, site4_.parentId as parentId1_3_, site4_.timeZone as timeZone1_3_, site4_.familyId as familyId1_3_, site4_.externalSiteAccessControl as external7_1_3_, site4_.canonicalDomainId as canonic10_1_3_, folder5_.id as id17_4_, folder5_.createTimestamp as createTi2_17_4_, folder5_.hibernateVersionId as hibernat3_17_4_, folder5_.lastUpdateTimestamp as lastUpda4_17_4_, folder5_.leftCol as leftCol17_4_, folder5_.rightCol as rightCol17_4_, folder5_.siteId as siteId17_4_, folder5_.title as title17_4_ from TextBlockVersionHistory textblockv0_ left outer join TextBlockVersion textblockv1_ on textblockv0_.activeVersionId=textblockv1_.id left outer join TextBlockVersionHistory textblockv2_ on textblockv1_.versionHistoryId=textblockv2_.id left outer join TextBlock textblock3_ on textblockv0_.id=textblock3_.versionHistoryId and ? = textblock3_1_.siteId -- ************************************************** left outer join AbstractContentObject textblock3_1_ on textblock3_.id=textblock3_1_.id left outer join Site site4_ on textblock3_1_.siteId=site4_.id left outer join Folder folder5_ on textblock3_1_.folderId=folder5_.id where textblockv0_.id=? The highlighted condition is applied via a filter on AbstractContentObject: @javax.persistence.Entity @Inheritance(strategy = InheritanceType.JOINED) @Filter(name = "siteVisibility", condition = ":siteId = siteId") @Table(uniqueConstraints = @UniqueConstraint( columnNames = { "folderId", "order"})) public abstract class AbstractContentObject However, the actual SQL condition is supplied to the wrong LEFT OUTER JOIN. It should be supplied against the AbstractContentObject JOIN that immediately follows the condition. I.e. move the condition down three lines, and it should work. -- 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, 3 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2365) Incorrect parameter order for parameters used as map-key in HQL

by Hendrik D (JIRA)

Incorrect parameter order for parameters used as map-key in HQL --------------------------------------------------------------- Key: HHH-2365 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2365 Project: Hibernate3 Type: Bug Components: query-hql Versions: 3.2.1 Reporter: Hendrik D When using parameters in HQL for the key of a domain object map in the where-clause, the query parsing mechanism results in an SQL query with the parameters used in the wrong places. Since my real domain objects require you to know too much of the application I'm writing, I'll describe the problem with a simplified setup: CLASSES: ------- class Foo { int id; int meaninglessNumber; Map<Language, Document> documents; } class Document { int id; String name; } class Language { String code; } TABLES: ------- FOO id meaninglessNumber documents_link_id DOCUMENTS_LINK documents_link_id language_code document_id name LANGUAGE language_code Now, let't try to retrieve all Foo that contain an english document with name "English", and have a meaninglessNumber of '5'. This is the HQL I produce: from Foo as foo where foo.meaninglessNumber = param1 and foo.documents[:param2]=:param3 These are the parameter values: param1 = int 5 param2 = Language {code="en"} param3 = String "English" I expect an sql query like this: select * from foo foo0_ inner join documents documents1_ where foo0_.documents_link_id = documents1_.documents_link_id and documents1_.language_code = 'en' and foo0_.meaninglessNumber = 5 and documents1_.name = 'English' But instead, the real query looks like this: select * from foo foo0_ inner join documents documents1_ where foo0_.documents_link_id = documents1_.documents_link_id and documents1_.language_code = 5 and foo0_.meaninglessNumber = 'en' and documents1_.name = 'English' The subtle difference is, that the parameters param1 and param2 seem to be switched! A lot of debugging pointed out that the order of the indexes is determined based on the HQL, resulting in the following indexes: param1 -> 1 param2 -> 2 param3 -> 3 In the generated SQL, all parameters are replaced by '?', and on execution, these are replaced one by one, following the order of the parameter indexes. While creating the SQL, the map key parameter is transformed into 'documents1_.language_code = ?'. No problem here, but this condition is placed in the beginning of the where clause, before the use of parameter param1. The indexes of the parameters should become: param2 -> 1 param1 -> 2 param3 -> 3 But this is never done! I see 3 possible ways to fix this: - Recalculate the indexes of the parameters when the sql is generated - Generate the sql in the right position, so the order of the parameters stays the same - Use named parameters in the sql and only replace them with '?' right before creating the PreparedStatement. This seems to me the most reliable way, but I guess I'm missing the point of calculating the parameter indexes and replacing them with '?' immediately... Hendrik -- 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, 3 months

3
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2007