July 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2413) Offer a way to log bound jdbc parameters in a uniform way for UserType implementors

by Baptiste MATHUS (JIRA)

Offer a way to log bound jdbc parameters in a uniform way for UserType implementors ----------------------------------------------------------------------------------- Key: HHH-2413 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2413 Project: Hibernate3 Type: Improvement Versions: 3.2.2 Reporter: Baptiste MATHUS Priority: Minor At the moment, when someone implements a UserType, the bound parameters won't be displayed in not explicitly displayed via loggers. For example, here is what the code of NullableType.nullSafeGet() is : public final void nullSafeSet(PreparedStatement st, Object value, int index) throws HibernateException, SQLException { try { if ( value == null ) { if ( IS_TRACE_ENABLED ) { log().trace( "binding null to parameter: " + index ); } st.setNull( index, sqlType() ); } else { if ( IS_TRACE_ENABLED ) { log().trace( "binding '" + toString( value ) + "' to parameter: " + index ); } set( st, value, index ); } } catch ( RuntimeException re ) { log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + re.getMessage() ); throw re; } catch ( SQLException se ) { log().info( "could not bind value '" + toString( value ) + "' to parameter: " + index + "; " + se.getMessage() ); throw se; } } IMO, it would be quite a good thing to provide some method in Hibernate, something like logBoundParameter() that would do the log like above : > log().trace( "binding '" + toString( value ) + "' to parameter: " + index ); This method could then be just called by implementors so as to guaranty the display is always the same about bound parameters. Even more, I think it should use a special logger, just like the org.hibernate.SQL one to display this parameters. In fact, at the moment, I feel the reference documentation is not very clear about this : see http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat.... It says : > org.hibernate.type Log all JDBC parameters But that's not completely true: it will only log bound parameters that are parameters typed with standard types coming from the org.hibernate.type package. Any custom UserType won't display anything until you: 1) put the right log4j line for the package where your userType is located ; 2) think about explicitly logging those parameter values in your custom UserType (cf. my first point). I'm not sure I made myself totally clear,. If so, please let me know. If you think that would be worth an improvement, I'll give a look to provide a patch for this. Thanks a lot. -- 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

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2480) Unify join fetch behavior or HQL and Criteria APIs

by Christian Bauer (JIRA)

Unify join fetch behavior or HQL and Criteria APIs -------------------------------------------------- Key: HHH-2480 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2480 Project: Hibernate3 Type: Improvement Components: query-hql, query-criteria Reporter: Christian Bauer Priority: Critical Fix For: 3.3 Can we consider changing the criteria API in 3.3 so that DISTINCT_ROOT_ENTITY is the default transformer? 10:28 I remember that detecting "fetch" in HQL and applying this transformer is already on the list, right? 10:29 or introduce config options for both APIs, so users can switch the default transformer 10:30 also, verify this please: http://www.hibernate.org/117.html#A12 Steve 2:31 we should try to detect if any fetches are present 2:31 otherwise DISTINCT_ROOT_ENTITY presents unecessary overhead 2:31 i dont recall such a discussion regarding that feature in HQL 2:32 another option is sorta like i'm planning in other areas: fallback to subselect fetching -- 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

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2272) Serious performance problems when saving large amount of transient entities with collections of transient entities

by Markus Heiden (JIRA)

Serious performance problems when saving large amount of transient entities with collections of transient entities ------------------------------------------------------------------------------------------------------------------ Key: HHH-2272 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2272 Project: Hibernate3 Type: Task Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0 on Oracle 9.2 Reporter: Markus Heiden When saving many (e.g. 50000) transient entities with a collection of transient entities, for each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection. This leads to an enormous amount (> 1000000) of iterations over all entities and over all collection elements of each entity. Especially when one saves only the same type of entities this leads to times of hours(!) even on a fast machine before any insert statement is even issued. This issue is related to HHH-1612, but fixing issue HHH-1612 won't resolve this problem (I have explored this with a hack which fixes HHH-1612). In my eyes there are two ways to solve this problem: 1) When cascading the save of a parent, the parent cascade can fill the persistence context with information about its collection elements. E.g. before cascading the save to a collection a parent can add a (child, parent) pair to a map in the persistence context to avoid the above described iterations. Then a simple Map#get() would be sufficient in most cases to get the parent. 2) When cascading, the parent has to be passed with the cascaded (e.g. saved) element. But this is no good solution, because it affects some well known hibernate apis. -- 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

5
13
0 / 0

[Hibernate-JIRA] Created: (HBX-936) Project cannot be deleted when there is console configuration associated with the project

by Dariusz Tylus (JIRA)

Project cannot be deleted when there is console configuration associated with the project ----------------------------------------------------------------------------------------- Key: HBX-936 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-936 Project: Hibernate Tools Issue Type: Bug Components: consoleconfiguration, eclipse Affects Versions: 3.2beta9 Environment: Eclipse 3.2, Windows XP, jdk1.5.0_8 Reporter: Dariusz Tylus Project cannot be deleted when there is console configuration associated with the project: Use case: 1. Create java project 2. Put jdbc driver jar file into lib filder (in the project) 3. Create console configuration for this project 4. Swich to the hibernate perspective and expand the tree for just created console configuration 5. Delete the console configuration 6. Delete the project and select option 'Also delete contents under....' There is following error: == Problems encountered while deleting resources. Could not delete: /hbmtest. Problems encountered while deleting resources. Problems encountered while deleting files. Could not delete: C:\work\ORM\_tests\orm\hbmtest\lib\hsqldb-1_7_2_9.jar. Could not delete: C:\work\ORM\_tests\orm\hbmtest\lib. == The problem is that jvm keeps lock on the jar file so it cannot be deleted. Console configuration also keeps reference to the driver class. Could the console configuration release all resources when it is deleted? Thenx, Dariusz -- 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

2
5
0 / 0

[Hibernate-JIRA] Created: (EJB-272) PostRemove being called before entity is actually deleted

by Paul (JIRA)

PostRemove being called before entity is actually deleted --------------------------------------------------------- Key: EJB-272 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-272 Project: Hibernate Entity Manager Type: Bug Versions: 3.2.1 Environment: Hibernate 3.2.1GA Entity Manager Hibernate core 3.2.2 GA Oracle 9i Windows XP professional service pack 2 No application server is being used. Reporter: Paul I have an EntityListener with a method annotated with postremove. It seems that the method is being called before the actual entity is deleted from the database. When configuring log4j with "debug" logging it appears that the method is being called after the PreparedStatement is created and configured but before executeUpdate() is called. I see the following statements in my log file before my listener is called 14:06:27,024 DEBUG AbstractBatcher:476 - preparing statement 14:06:27,024 DEBUG IntegerType:133 - binding '59532' to parameter: 1 My listener is called next. Then, the prepared statement is executed. This violates the EJB3 spec. The EJB3 spec states "The PostPersist and PostRemove methods will be invoked after the database insert and delete operations respectively." -- 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, 1 month

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2609) Delete with multiple nested sub-queries generates invalid SQL (on Postgresql)

by Michael Barker (JIRA)

Delete with multiple nested sub-queries generates invalid SQL (on Postgresql) ----------------------------------------------------------------------------- Key: HHH-2609 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2609 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.4 Environment: Linux, JDK 1.5. Reporter: Michael Barker Attachments: delete-ejbql-problem.zip When a delete uses multiple nest subqueries the resulting SQL query generated is invalid. E.g. the EJB-QL: DELETE Foo f WHERE f.fooId NOT IN (SELECT bar.fooId FROM Bar bar) AND f.fooId NOT IN (SELECT baz.fooId FROM Baz baz) or DELETE Foo WHERE fooId NOT IN (SELECT fooId FROM Bar) AND fooId NOT IN (SELECT fooId FROM Baz) Generates the following: delete from Foo where (fooId not in (select bar1_.fooId from Bar bar1_)) and (foo0_.fooId not in (select baz2_.fooId from Baz baz2_)) Will fail because the field "foo0_.fooId" should be "fooId", "foo0_" is not declared. At test case is attached. -- 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, 1 month

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2576) Allow native-sql to have placeholders for default schema and catalog

by Max Rydahl Andersen (JIRA)

Allow native-sql to have placeholders for default schema and catalog -------------------------------------------------------------------- Key: HHH-2576 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2576 Project: Hibernate3 Issue Type: Improvement Components: query-sql Affects Versions: 3.2.3 Reporter: Max Rydahl Andersen we shold consider allowing something like: <sql-query name="queryName" callable="true"> { call ${default_schema}.storedProcName() } </sql-query> similar for normal SQL queries too. <sql-query name="queryName"> select * from ${default_schema}.CUSTOMER x where ... </sql-query> Maybe ${catalogschema} should be allowed to which would be the full prefix needed dependent on the dialect and would free one from having both catalog and schema + poper seperators in there. -- 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, 1 month

5
42
0 / 0

[Hibernate-JIRA] Created: (HHH-2142) PersistentMap.put(), remove() may return UNKNOWN object that can cause ClassCastException in client code

by Andrzej Miazga (JIRA)

PersistentMap.put(), remove() may return UNKNOWN object that can cause ClassCastException in client code -------------------------------------------------------------------------------------------------------- Key: HHH-2142 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2142 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr5 Reporter: Andrzej Miazga Here is some code in Hibernate 3.2.0cr5 that may cause this behaviour. I'm not sure if this is a bug but it surely affects the client code. AbstractPersistentCollection: protected Object readElementByIndex(Object index) { if (!initialized) { ... return persister.getElementByIndex( entry.getLoadedKey(), index, session, owner ); } ... return UNKNOWN; } PersistentMap (extends AbstractPersistentCollection): public Object put(Object key, Object value) { if ( isPutQueueEnabled() ) { Object old = readElementByIndex( key ); queueOperation( new Put( key, value, old ) ); return old; } ... So, there is a possibility to return UNKNOWN instance (MarkerObject) to the client code as the result of Map.put(). In version 3.1.3 this worked fine, but the implementation was different: public Object put(Object key, Object value) { Object old = isPutQueueEnabled() ? readElementByIndex(key) : UNKNOWN; if ( old==UNKNOWN ) { write(); return map.put(key, value); } ... } -- 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, 1 month

9
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2421) Cascading Delete In Wrong Order

by CannonBall (JIRA)

Cascading Delete In Wrong Order ------------------------------- Key: HHH-2421 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2421 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.1 Environment: Hibernate 3.2.1, Java5, MySQL 5 (InnoDB) Reporter: CannonBall Priority: Trivial Mapping Document: <hibernate-mapping> <class name="scratchpad.hibernate.A"> <id name="id"> <generator class="increment"/> </id> <list name="bs" cascade="all,delete-orphan"> <key column="bId"/> <list-index column="idx"/> <one-to-many class="scratchpad.hibernate.B"/> </list> </class> <class name="scratchpad.hibernate.B"> <id name="id"> <generator class="increment"/> </id> <many-to-one name="a" column="aId" insert="false" update="false"/> <many-to-one name="c" column="cId" not-null="false"/> </class> <class name="scratchpad.hibernate.C"> <id name="id"> <generator class="increment"/> </id> </class> </hibernate-mapping> Code between sessionFactory.openSession() and session.close(): long id; SessionFactory factory = new Configuration().configure() .buildSessionFactory(); try { Session s = factory.openSession(); try { Transaction tx = s.beginTransaction(); try { C c = new C(); s.save(c); B b = new B(); b.setC(c); A a = new A(); a.getBs().add(b); s.save(a); tx.commit(); id = b.getId(); } catch (Exception e) { try { tx.rollback(); } catch (Exception e2) { // do nothing } throw e; } } finally { s.close(); } s = factory.openSession(); try { Transaction tx = s.beginTransaction(); try { A a = (A) s.load(A.class, id); B b = a.getBs().get(0); a.getBs().remove(b); s.delete(b.getC()); tx.commit(); } catch (Exception e) { try { tx.rollback(); } catch (Exception e2) { // do nothing } throw e; } } finally { s.close(); } } finally { factory.close(); } The generated SQL (show_sql=true): Hibernate: select max(id) from C Hibernate: select max(id) from A Hibernate: select max(id) from B Hibernate: insert into C (id) values (?) Hibernate: insert into A (id) values (?) Hibernate: insert into B (cId, id) values (?, ?) Hibernate: update B set bId=?, idx=? where id=? Hibernate: select a0_.id as id0_0_ from A a0_ where a0_.id=? Hibernate: select bs0_.bId as bId1_, bs0_.id as id1_, bs0_.idx as idx1_, bs0_.id as id1_0_, bs0_.aId as aId1_0_, bs0_.cId as cId1_0_ from B bs0_ where bs0_.bId=? Hibernate: select c0_.id as id2_0_ from C c0_ where c0_.id=? Hibernate: update B set cId=? where id=? Hibernate: update B set bId=null, idx=null where bId=? Hibernate: delete from C where id=? Hibernate: delete from B where id=? When you have a collection that is mapped with a cascade of 'delete-orphan', when removing an entity from the collection, the corresponding orphan delete is scheduled at the end of the session's deletions queue. As you can see from my example above, when you have a relationship of A has a list of B's, B has a relationship with C, removing B from the A's list results in its deletion after C's deletion (despite the order of statements dictating C's deletion after B's). If I were to make B's relationship to C not-null, the above code would result in a FK constraint error as C would be removed before B. You could force the correct removal of B before C with a manual delete of B like so: A a = (A) s.load(A.class, id); B b = a.getBs().get(0); C c = b.getC(); a.getBs().remove(b); s.delete(b); s.delete(c); -- 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, 1 month

5
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2390) select clause alias in HQL is mapped incosistently in SQL.

by Natto Lover (JIRA)

select clause alias in HQL is mapped incosistently in SQL. ---------------------------------------------------------- Key: HHH-2390 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2390 Project: Hibernate3 Type: Bug Components: query-hql Versions: 3.2.2 Environment: Win2K+JDK1.5+Eclipse3.2.1+Hibernate3.2.2, Solaris Express x86+MySQL5 Reporter: Natto Lover Attachments: HQLTest.zip Hi. I was told at the users forum to post a test case here. I give an alias to an expression in the select clause, try to refer it in the where clause. In SQL, Hibernate replaces the alias in the select clause, but leaves the original text in the where clause. This is the HQL: select (p.endDate - p.startDate) as period, p from Project as p where period > :period_length See above where the alias 'period' appears. Now, This is the resulting SQL: select project0_.end_date-project0_.start_date as col_0_0_, project0_.id as col_1_0_, project0_.id as id0_, project0_.name as name0_, project0_.start_date as start3_0_, project0_.end_date as end4_0_ from PROJECT project0_ where period>? Note above the 'period' that was in the select clause is replaced with machine generated "col_0_0_", but that is not applied for the alias in the where clause. Please find attached a test case archive. Two HQL statements are tried. One uses the alias in the where clause, the other one uses the alias in the order by clause. -- 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, 1 month

4
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2007