April 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-317) Rename Global- and LocalExecutionContext

by Hardy Ferentschik (JIRA)

Rename Global- and LocalExecutionContext ---------------------------------------- Key: HV-317 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-317 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.1.0.Beta1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.1.0 -- 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

14 years, 5 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5166) Inconsistent session state with merge/evict on cascade="all" association

by Alexandre FRADIN (JIRA)

Inconsistent session state with merge/evict on cascade="all" association ------------------------------------------------------------------------ Key: HHH-5166 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5166 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.3.2 Environment: Reproducted on : Hibernate-core 3.3.2 and 3.5.1-Final DB2 and HSQL DB with annotation and classic hbm mapping Reporter: Alexandre FRADIN Priority: Critical Attachments: hibernate-test-merge-evict-cascade-all.zip My apologies for my English. I have entities User and Role with a many-to-many association mapped with cascade="all". So merge and evict operations on User should be applied to this association. When I do the following : 1) create user u existing in DB 2) add a new Role r to this user (this Role don't exists in DB) 3) merge u 4) evict the instance returned by the merge operation 5) use the same session for any operation 6) commit the session I get this exception : "org.hibernate.AssertionFailure: possible nonthreadsafe access to session". There is no thread issue. I think this is a standard way to use merge and evict operations. I think that merge and evict operations used on modified entities leave the session in an inconsistent state. See unit test wich reproduct this bug. Does a workaround exist for this bug? Regards. -- 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

14 years, 5 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5165) FetchMode=Eager not respected, N+1 SELECT Problem

by David Bernhard (JIRA)

FetchMode=Eager not respected, N+1 SELECT Problem ------------------------------------------------- Key: HHH-5165 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5165 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: (as Maven artifacts) org.hibernate:hibernate-core:jar:3.3.2.GA org.hibernate:hibernate-annotations:jar:3.4.0.GA org.hibernate:ejb3-persistence:jar:1.0.2.GA org.hibernate:hibernate-validator:jar:3.1.0.GA org.hibernate:hibernate-commons-annotations:jar:3.1.0.GA org.hibernate:hibernate-search:jar:3.1.0.GA org.hibernate:hibernate-entitymanager:jar:3.4.0.GA Reporter: David Bernhard Priority: Minor Two classes A, B with 1:n relationship. Fetching all instances of B with an empty DetachedCriteria instance does not repsect FetchMode.JOIN but issues a SELECT for each A (N+1 SELECT problem). This causes the bug: findByCriteria(DetachedCriteria.forClass(B.class)); This works - but I need that second setFetchMode: findByCriteria(DetachedCriteria.forClass(B.class) .setFetchMode("a", FetchMode.JOIN) .setFetchMode("a.bs", FetchMode.JOIN) ); HQL works too. Here are two classes that cause the bug: @Entity @Table(name = "A") @SequenceGenerator(name = "keyid_generator", sequenceName = "A_sequence") public class A extends AbstractIntKeyIntOptimisticLockingDto { private String name; private Set<B> bs; @OneToMany(mappedBy = "a", fetch = FetchType.EAGER) @Fetch(FetchMode.JOIN) public Set<B> getBs() { return bs; } public void setBs(Set<B> bs) { this.bs = bs; } public String getName() { return name; } public void setName(String name) { this.name = name; } } @Entity @Table(name = "B") @SequenceGenerator(name = "keyid_generator", sequenceName = "B_sequence") public class B extends AbstractIntKeyIntOptimisticLockingDto { private String name; private A a; @ManyToOne(fetch = FetchType.EAGER) @JoinColumn(name = "a", nullable = false, unique = false, updatable = false) @Fetch(FetchMode.JOIN) public A getA() { return a; } public void setA(A a) { this.a = a; } public String getName() { return name; } public void setName(String name) { this.name = name; } } -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5161) JPA 2.0 criteria queries do not use parameters for numeric fields

by Tarek Nabil (JIRA)

JPA 2.0 criteria queries do not use parameters for numeric fields ----------------------------------------------------------------- Key: HHH-5161 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5161 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-Final Environment: Hibernate 3.5.0 with Oracle DB. Reporter: Tarek Nabil Attachments: param-bug.zip Using the new JPA 2.0 criteria API to create a query whose where clause consists of one or more predicates, where one of those predicates compares a numeric (int or long) field in an entity to a certain value, the generated query uses the compared value literally in the query where it should have used a parameter. The attached test case illustrates the problem. It's a minimal Maven2 project which contains one domain class and one DAO. The domain class maps to the REGION entity from the Oracle HR schema which ships with any Oracle XE installation. I still included the script needed to create the table incase the schema is not available on the test environment. The DAO has one method which creates a query that selects a region by id and then extracts the set of parameters from the generated TypedQuery. The method then returns the size of the set to the test method which fails if the size is not greater than zero. The DAO method also executes the query and since Hibernate is configured to show the generated SQL, the following query is shown in standard output: select region0_.REGION_ID as REGION1_0_, region0_.REGION_NAME as REGION2_0_ from REGIONS region0_ where region0_.REGION_ID=1 Where the correct query should have been: select region0_.REGION_ID as REGION1_0_, region0_.REGION_NAME as REGION2_0_ from REGIONS region0_ where region0_.REGION_ID=? IMO, this is a major issue as it can have a severe impact on on Oracle DB performance as it will have to hard parse the query every time it's used with a different value. I've provided instructions on the minimal changes required to setup the Maven project in order to run the test case in "readme.txt". -- 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

14 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3852) error in generated sql from criteria api on an array property

by Elhanan Maayan (JIRA)

error in generated sql from criteria api on an array property -------------------------------------------------------------- Key: HHH-3852 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3852 Project: Hibernate Core Issue Type: Bug Components: query-criteria Affects Versions: 3.5 Environment: hibernate from trunk, database hqsldb. Reporter: Elhanan Maayan Attachments: ParentChildTest2.java i'm assuming this is hibernate 3.5 version as i took it from the trunk the test case ParentChildTest fails under testComplexCriteria, i believe i've managed to isolated the issue to this api: i'm attaching a modified version ParentChildTest, showing the criteria api and it's parallel hql counterpart, as you will see the criteria api fails while the hql version passes -- 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

14 years, 5 months

3
4
0 / 0

[Hibernate-JIRA] Updated: (HHH-1123) Cannot put more than 1000 elements in a InExpression

by Strong Liu (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123?page=c... ] Strong Liu updated HHH-1123: ---------------------------- Issue Type: Improvement (was: Bug) change this to improvment > Cannot put more than 1000 elements in a InExpression > ---------------------------------------------------- > > Key: HHH-1123 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1123 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Affects Versions: 3.1 rc2, 3.2.0.alpha1 > Environment: Oracle 9i > Reporter: Alexis Seigneurin > Assignee: Strong Liu > Attachments: Animal.hbm.xml, hibernate-inexpression-oracle-3.2.patch, LongInElementsTest.java, patch.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > The number of elements that we can put in a "in" expression is limited to a certain amount (1000 for Oracle, for instance). When creating a criteria query, the org.hibernate.criterion.InExpression class should split the expression into several smaller ones. > Attached is a patch which splits the expression by slices of 500 elements. For example, if we have 1001 elements to put in the "in" expression, the result would be : > (entity.field in (?, ?, ?...) or entity.field in (?, ?, ?...) or entity.field in (?)) > The surrounding parantheses are useful to avoid problems with other conditions (a "and" condition taking over the one of the "or" conditions). -- 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

14 years, 5 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-314) ThreadLocal in ContextHolder causes memory leak when deployed in a web container

by François Terrier (JIRA)

ThreadLocal in ContextHolder causes memory leak when deployed in a web container -------------------------------------------------------------------------------- Key: HSEARCH-314 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-314 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.1.0.CR1 Environment: Hibernate 3.3.1.GA Tomcat 6.0.18 Spring 2.5.6 Java OpenJDK 1.6 Reporter: François Terrier The SearchFactory has a static ThreadLocal variables which holds a reference to the SearchFactoryImpl. The ThreadLocal is not cleared when the application is undeployed, causing a memory leak. -- 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

14 years, 5 months

4
12
0 / 0

[Hibernate-JIRA] Created: (HHH-5158) UpdateTimestampsCache is not invalidated for bulk operations

by Anders Wallgren (JIRA)

UpdateTimestampsCache is not invalidated for bulk operations ------------------------------------------------------------ Key: HHH-5158 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5158 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Environment: 3.5.1, any database Reporter: Anders Wallgren Priority: Critical {{ActionQueue.addAction(BulkOperationCleanupAction cleanupAction)}} doesn't retain the cleanupAction to be executed. Since the {{BulkOperationCleanupAction}} is never executed, the property spaces (aka {{BulkOperationCleanupAction.affectedTablespaces}} are never invalidated, as that's done in execute. -- 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

14 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5167) NullPointerException on double-save of versioned entity

by Robert Hailey (JIRA)

NullPointerException on double-save of versioned entity ------------------------------------------------------- Key: HHH-5167 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5167 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: PostgreSQL 8.3.3, Hibernate 3.3.2.GA (2009-06-24) Reporter: Robert Hailey Priority: Minor (psuedocode) VersionedPojo v=new VersionedPojo(); session.save(v); String secondary=functionNeedingId(v.getId()); v.setSecondary(secondary); session.saveOrUpdate(v); -- A common example of a function needing an id might include the saving of a many-to-one relationships. This stack trace has been seen in forum posts and is very likely to be this same issue. -- java.lang.NullPointerException at org.hibernate.type.LongType.next(LongType.java:79) at org.hibernate.engine.Versioning.increment(Versioning.java:131) at org.hibernate.event.def.DefaultFlushEntityEventListener.getNextVersion(DefaultFlushEntityEventListener.java:387) at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:279) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:151) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:219) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:99) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:49) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:366) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:137) -- 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

14 years, 5 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3030) NullPointerException happens in versioning

by John (JIRA)

NullPointerException happens in versioning ------------------------------------------ Key: HHH-3030 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3030 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: any Reporter: John Priority: Minor Here is the stack trace: java.lang.NullPointerException at org.hibernate.type.IntegerType.next(IntegerType.java:59) at org.hibernate.engine.Versioning.increment(Versioning.java:25) at org.hibernate.event.def.DefaultFlushEntityEventListener.getNextVersion(DefaultFlushEntityEventListener.java:358) at org.hibernate.event.def.DefaultFlushEntityEventListener.scheduleUpdate(DefaultFlushEntityEventListener.java:250) at org.hibernate.event.def.DefaultFlushEntityEventListener.onFlushEntity(DefaultFlushEntityEventListener.java:121) at org.hibernate.event.def.AbstractFlushingEventListener.flushEntities(AbstractFlushingEventListener.java:196) at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:76) at org.hibernate.event.def.DefaultAutoFlushEventListener.onAutoFlush(DefaultAutoFlushEventListener.java:35) at org.hibernate.impl.SessionImpl.autoFlushIfRequired(SessionImpl.java:969) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1114) at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79) ...... The code is: public Object next(Object current, SessionImplementor session) { return new Integer( ( (Integer) current ).intValue() + 1 ); } Should there be a null checking for the object "current"? -- 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

14 years, 5 months

10
11
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2010