January 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2969) DB2Dialect Clob SchemaExport uses default length even if no length set

by Philippe Mouawad (JIRA)

DB2Dialect Clob SchemaExport uses default length even if no length set ---------------------------------------------------------------------- Key: HHH-2969 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2969 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, DB2 8, DB2 9 Reporter: Philippe Mouawad Attachments: db2-clob-schemaExport-patch.txt I have this property in my mapping: <property name="argumentsValues" column="cte_arguments_values" type="text" not-null="true" /> Notice no length is set. Hibernate schema Export generates: cte_arguments_names clob(255) not null, Same problem occurs for Clob and Blob. This is due to the following lines in org.hibernate.dialect.DB2Dialect: registerColumnType( Types.BLOB, "blob($l)" ); registerColumnType( Types.CLOB, "clob($l)" ); Attached is the patch. There would be another solution to test that Column has no length set. Philippe. www.ubik-ingenierie.com -- 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

11 years, 6 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HV-399) Make allowOneValidationPerPath in ValidationContext a configurable option

by Hardy Ferentschik (JIRA)

Make allowOneValidationPerPath in ValidationContext a configurable option ------------------------------------------------------------------------- Key: HV-399 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-399 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0.Beta1 Currently this option is hard-wired to be _true_ to align with the spec. Making it configurable will be a Hibernate Validator specific feature. -- 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

11 years, 6 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3298) Hibernate does not correcly apply LockMode.UPGRADE when performing a polymorphic select to a leaf-class via a mapped superclass on Oracle

by Mike Everett (JIRA)

Hibernate does not correcly apply LockMode.UPGRADE when performing a polymorphic select to a leaf-class via a mapped superclass on Oracle ----------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3298 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3298 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, Oracle 10gR2 Reporter: Mike Everett Attachments: src.zip Greetings All, I'm experiencing an issue with Hibernate generated SQL when I attempt to retrieve a union-subclass entity via a concrete mapped superclass with LockMode.UPGRADE. Hibernate will generate SQL with a UNION ALL of the sub-classes and then apply FOR UPDATE to the query which is not allowed with Oracle. This leads to the following error: java.sql.SQLException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. It seems that "etc." part includes UNION and UNION ALL. Example with three classes: Entity (abstract) <--extends--- ConcreteInheritorOne (concrete) <--extends-- ConcreteInheritorTwo (concrete) assume: inheritorTwoId == the id of an item of class ConcreteInheritorTwo session == a Hibernate Session // These lookups will cause the error Entity e = (Entity) session.get(Entity.class, inheritorTwoId, LockMode.UPGRADE); Entity e = (Entity) session.get(ConcreteInheritorOne.class, inheritorTwoId, LockMode.UPGRADE); // This will not cause the error Entity e = (Entity) session.get(ConcreteInheritorTwo.class, inheritorTwoId, LockMode.UPGRADE); I have attached entity classes and a Test class which illustrate this effect. I spelunked into the code a bit, but an easy fix did not present itself to my hibernate-code-virgin eyes. Thanks for making Hibernate great! --Mje #### Workaround #### If anyone else is experiencing this problem, I've implemented code similar to the method below as a work-around in an abstraction layer: public Object getEntityForUpdate(Class entityClass, String entityId) { Session s = getSession(); ClassMetadata meta = s.getSessionFactory().getClassMetadata(entityClass); Boolean doTwoPhaseLock = false; if(meta instanceof UnionSubclassEntityPersister) { if(((UnionSubclassEntityPersister)meta).getEntityMetamodel().getSubclassEntityNames().size() > 1) doTwoPhaseLock = true; } if(doTwoPhaseLock) { Entity e = (Entity)s.get(entityClass, entityId); System.out.println("Using Two-Phase Lock on: EntityId[" + entityId + "] EntityClass[" + entityClass.getName() + "]"); s.lock(e, LockMode.UPGRADE); return e; } else { System.out.println("Using One-Phase Lock on: EntityId[" + entityId + "] EntityClass[" + entityClass.getName() + "]"); return s.get(entityClass, entityId, LockMode.UPGRADE); } } #### Hibernate Generated SQL Example #### select entity0_.id as id6_0_, entity0_.versionNumber as versionN2_6_0_, entity0_.clazz_ as clazz_0_ from ( select versionNumber, id, 2 as clazz_ from BASE_ConcreteInheritorTwo union all select versionNumber, id, 1 as clazz_ from BASE_ConcreteInheritorOne ) entity0_ where entity0_.id=? for update #### Stack Trace #### 15:18:14,484 ERROR JDBCExceptionReporter:78 - ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. 15:18:14,484 INFO DefaultLoadEventListener:111 - Error performing load command org.hibernate.exception.SQLGrammarException: could not load an entity: [org.example.domain.hibernate.Entity#1211505494256] at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.loadEntity(Loader.java:1874) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:48) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:42) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3049) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:399) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:375) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:139) at org.hibernate.event.def.DefaultLoadEventListener.lockAndLoad(DefaultLoadEventListener.java:297) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:106) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:878) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:869) at org.hibernate.impl.SessionImpl.get(SessionImpl.java:864) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.hibernate.context.ThreadLocalSessionContext$TransactionProtectionWrapper.invoke(ThreadLocalSessionContext.java:301) at $Proxy0.get(Unknown Source) at org.example.test.Test.doTest2(Test.java:68) at org.example.test.Test.main(Test.java:35) Caused by: java.sql.SQLException: ORA-02014: cannot select FOR UPDATE from view with DISTINCT, GROUP BY, etc. at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:810) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039) at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:850) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1134) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3384) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:186) at org.hibernate.loader.Loader.getResultSet(Loader.java:1787) at org.hibernate.loader.Loader.doQuery(Loader.java:674) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.loadEntity(Loader.java:1860) ... 19 more -- 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

11 years, 6 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5836) Mapping collection of entities with same name and notnull constraints from two different entities results in duplicate property mapping of Backref

by Milan Brich (JIRA)

Mapping collection of entities with same name and notnull constraints from two different entities results in duplicate property mapping of Backref -------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5836 Project: Hibernate Core Issue Type: Bug Components: annotations Affects Versions: 3.5.6 Reporter: Milan Brich Attachments: hibernate-backref-bug.zip When two entities have OneToMany relationship to third entity and the collection name is same in both entities and nullable is set to false. Then exception written below is thrown. Caused by: org.hibernate.MappingException: Duplicate property mapping of _parentsBackref found in cz.csas.persistence.test.Parent at org.hibernate.mapping.PersistentClass.checkPropertyDuplication(PersistentClass.java:483) at org.hibernate.mapping.PersistentClass.validate(PersistentClass.java:473) at org.hibernate.mapping.RootClass.validate(RootClass.java:236) at org.hibernate.cfg.Configuration.validate(Configuration.java:1193) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1378) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:954) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:892) ... 58 more Attached annotated entities. -- 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

11 years, 6 months

5
15
0 / 0

[Hibernate-JIRA] Created: (HHH-3011) merge() optimization for Oracle dialect

by MG (JIRA)

merge() optimization for Oracle dialect --------------------------------------- Key: HHH-3011 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3011 Project: Hibernate3 Issue Type: Improvement Components: core Reporter: MG Priority: Minor merge() optimization for Oracle dialect. Since 9i Oracle has a MERGE statement which is very useful to save round trips to database in merge() call which will make dramatic improvement for performance of loading large row sets. MERGE command processes the conditional INSERT-or-UPDATE within a single statement. So instead of doing 'select' first to detect whether entity is in database or not (This is one round trip to DB) and then issuing 'update' or 'insert' all of it could be done in one statement with no extra round trips using oracle SQL MERGE statement. http://www.oracle.com/technology/products/oracle9i/daily/Aug24.html -- 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

11 years, 6 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3317) Entities saved within onPreUpdate() never inserted into db when id generator is sequenze (f.e. oracle)

by Martin Backhaus (JIRA)

Entities saved within onPreUpdate() never inserted into db when id generator is sequenze (f.e. oracle) ------------------------------------------------------------------------------------------------------ Key: HHH-3317 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3317 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: hibernate3.2.6.ga.jar, Oracle 10 Reporter: Martin Backhaus Priority: Minor If you save (insert) a entity within the event preUpdate and the id is a oracle-sequenze, hibernate put the entity to insert in the session-ActionQueue, BUT NEVER INSERTS it. If you use mysql/hsql... where the id is differently generated, the insert happens immediately and no put to the ActionQueue occures. As workaround you can queue the object (to insert) yourself and call save() within the postUpdate-Event. I use this events for historizing some stuff. Inserts within onDelete() works fine. the ids are annotated as shown here: @Id @GeneratedValue(strategy = GenerationType.AUTO) protected Long id = null; -- 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

11 years, 6 months

4
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2657) Bulk select using primary key or natural id

by charbel (JIRA)

Bulk select using primary key or natural id ------------------------------------------- Key: HHH-2657 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2657 Project: Hibernate3 Issue Type: Improvement Reporter: charbel I think that the following methods are really useful once we use hibernate with huge datas in the database: Object[] get(Class,Object[] id): ---------------------------------------- return objects giving their primary key. First check in cache if it exists, if not either use a select in () either create a temporary table if too many ids. Object[] getUsingNaturalId(Class,Object[] id): ---------------------------------------- return objects giving their natural id. the same thing than before. Be careful on the fact that the primary key and the naturalid can be composite objects. -- 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

11 years, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2331) bulk deletes on ID must not use HT_ tables

by Amir Pashazadeh (JIRA)

bulk deletes on ID must not use HT_ tables ------------------------------------------ Key: HHH-2331 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2331 Project: Hibernate3 Type: Improvement Components: core Reporter: Amir Pashazadeh when using bulk deletes hibernate inserts ids of rows which must be deleted in a temporary table (with HT_ prefix); I believe that's just for knowing primary keys of objects which must be deleted and updating caches. so if that is the reason there is no need to do so when deleting on primary key property, (for example "delete from MyEntity where 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

11 years, 6 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-654) Generated SQL includes a column named "null" when referencing a map entry by key and using @LazyCollection(LazyCollectionOption.EXTRA)

by Paul Roe (JIRA)

Generated SQL includes a column named "null" when referencing a map entry by key and using @LazyCollection(LazyCollectionOption.EXTRA) -------------------------------------------------------------------------------------------------------------------------------------- Key: ANN-654 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-654 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.2.0.ga Environment: Oracle 10g, hibernate 3.2 Reporter: Paul Roe We have an Product entity with a map of RegionProduct by Region. @MapKey(name="region") @OneToMany(mappedBy="product", targetEntity= RegionProductImpl.class, fetch = FetchType.LAZY) @LazyCollection(LazyCollectionOption.EXTRA) private Map<Region, RegionProduct> regionProducts = new HashMap<Region, RegionProduct>(); When accessing an element of the map by key, the SQL that is generated includes a "null" column in the WHERE condition. where regionprod0_.PROD_ID=? and regionprod0_.null=? resulting in the stack trace org.hibernate.exception.SQLGrammarException: could not collection element by index at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:67) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:43) at org.hibernate.loader.Loader.loadEntity(Loader.java:1841) at org.hibernate.loader.entity.CollectionElementLoader.loadElement(CollectionElementLoader.java:72) at org.hibernate.persister.collection.OneToManyPersister.getElementByIndex(OneToManyPersister.java:360) at org.hibernate.collection.AbstractPersistentCollection.readElementByIndex(AbstractPersistentCollection.java:158) at org.hibernate.collection.PersistentMap.get(PersistentMap.java:146) Iterating over the collection works successfully, but populates the entire collection, which is what Extra-Lazy is meant to avoid. -- 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

11 years, 6 months

6
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3949) Intrumentated to one relations can not be join fetched

by Gérald Quintana (JIRA)

Intrumentated to one relations can not be join fetched ------------------------------------------------------ Key: HHH-3949 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3949 Project: Hibernate Core Issue Type: Bug Components: core, query-criteria, query-hql Affects Versions: 3.3.1 Reporter: Gérald Quintana 1) Relation Person -> Vehicle is annotated @OneToOne(optional=true, mappedBy="driver", fetch=FetchType.LAZY) @LazyToOne(LazyToOneOption.NO_PROXY) private Vehicle vehicle; 2) Both entities are instrumented with Javassist 3) Query (HQL or Criteria) Person and Vehicle: from Person p left join fetch p.vehicle => SQL query is correct but Vehicles are not loaded -- 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

11 years, 6 months

4
4
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2011