May 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3674) Expose SchemaUpdate#haltOnError as a configuration property

by Chris Bredesen (JIRA)

Expose SchemaUpdate#haltOnError as a configuration property ----------------------------------------------------------- Key: HHH-3674 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3674 Project: Hibernate Core Issue Type: New Feature Components: documentation, metamodel Reporter: Chris Bredesen Assignee: Chris Bredesen Priority: Minor SchemaUpdate currently collects and logs any Exceptions caught during its work. While the Exceptions are logged, Hibernate is allowed to startup successfully. This feature request allows for a setting to flip this behavior such that Hibernate will not start if one or more Exceptions are encountered during SchemaUpdate (in test environments, of course). Proposed configuration option is hibernate.hbm2ddl.haltOnError -- 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

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6067) Infinispan custom commands to solve entity/collection region better

by Galder Zamarreno (JIRA)

Infinispan custom commands to solve entity/collection region better ------------------------------------------------------------------- Key: HHH-6067 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6067 Project: Hibernate Core Issue Type: Improvement Components: caching (L2) Reporter: Galder Zamarreno Assignee: Galder Zamarreno Provide a better solution for HHH-3818 using Infinispan's new SPI to define your own commands, ISPN-256 -- 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

12 years, 7 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4713) Avoid using same cache instance for storing CacheValue and evictAll notifications

by Galder Zamarreno (JIRA)

Avoid using same cache instance for storing CacheValue and evictAll notifications --------------------------------------------------------------------------------- Key: HHH-4713 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4713 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.5.0-Beta-2 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.5 Store evictAll information in a separate infinispan cache instance in order to avoid doing stuff like this in BaseRegion.toMap which could be quite expensive in the context of SecondLevelCacheStatistics calculations: public Map toMap() { if (checkValid()) { // If copying causes issues, provide a lazily loaded Map Map map = new HashMap(); Set<Map.Entry> entries = cacheAdapter.toMap().entrySet(); for (Map.Entry entry : entries) { Object key = entry.getKey(); if (!CacheHelper.isEvictAllNotification(key)) { map.put(key, entry.getValue()); } } return map; } return Collections.EMPTY_MAP; } -- 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

12 years, 7 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5348) java.lang.IllegalArgumentException: Cannot create TypedQuery for query with more than one return with AbstractEntityManager.createQuery(String jpaqlString, Class<T> resultClass) on View object

by nodje (JIRA)

java.lang.IllegalArgumentException: Cannot create TypedQuery for query with more than one return with AbstractEntityManager.createQuery(String jpaqlString, Class<T> resultClass) on View object ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-5348 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5348 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.3 Reporter: nodje I'm getting a java.lang.IllegalArgumentException: Cannot create TypedQuery for query with more than one return with a query that returns a View object. AbstractEntityManager:279, detects as many returns type as there is parameters in the View object, instead of one single result type, the View Object itself. QueryString example that fails with public <T> TypedQuery<T> createQuery(String jpaqlString, Class<T> resultClass): "select new WorkContractDto(wc.workContractStartDate, wc.workContractEndDate, wc.workContractEmployeeLastName, wc.workContractSendingStatus) from WorkContract wc where wc.workContractEmployeeLastName = ?1" -- 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

12 years, 7 months

15
38
0 / 0

[Hibernate-JIRA] Created: (HHH-5368) Not throwing Optimistic Lock when the entity is attached

by Fernando Rubbo (JIRA)

Not throwing Optimistic Lock when the entity is attached -------------------------------------------------------- Key: HHH-5368 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5368 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: windows XP, jboss 4.3 EAP, hibernate 3.4.2.sp1 Reporter: Fernando Rubbo Priority: Minor Hi Hibernate is not throwing Optimistic Lock when the entity is attached. It happens when the business rule sets a version in the attached entity that is less than its original (from database) version value. Take the following code as an example of the bug. // inserts A A a1 = new A(); a1.setName("A1"); dao.persist(a1); dao.flush(); dao.clear(); // as expected, the piece of code below works just fine final A a2 = dao.find(A.class, new BigDecimal(1)); a2.setName("A2"); dao.merge(a2); dao.flush(); dao.clear(); // as expected, this code fails due to Optimistic Lock try{ final A a3 = dao.find(A.class, new BigDecimal(1)); dao.clear(); a3.setName("A3"); a3.setVersion(0); //database verison is 1 dao.merge(a3); dao.flush(); Assert.fail(); }catch (Exception e) { System.out.println(e.getMessage()); // ignore }finally{ dao.clear(); } // unexpectedly, the piece of code below also works.. // even with the version being less than the one in the database // Note that this happens because hibernate is holding internaly the original version of the entity. // Even when the version is manually changed it keeps using the original one. final A a3 = dao.find(A.class, new BigDecimal(1)); a3.setName("A3"); a3.setVersion(0); //database verison is 1 dao.merge(a3); dao.flush(); dao.clear(); This problem can be handled by the business rule. For example, whether the version that comes from the screen is smaller than the one from the database it could throw an Optimistic Lock exception. However, it it was not handled, hibernate must take care of this in the same way it does with detached 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

12 years, 7 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-4694) Support "fake" many-to-one bidirectional relations

by Adam Warski (JIRA)

Support "fake" many-to-one bidirectional relations -------------------------------------------------- Key: HHH-4694 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4694 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski Assignee: Adam Warski Fix For: 3.5 Such relations are mapped with @OneToMany+@JoinColumn and @ManyToOne+@Column(insertable=false, updatable=false). This will be supported by an experimental @AuditMappedBy annotation. -- 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

12 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-460) Create a SerializableValidatorFactory wrapper that has enough information to either access or create a matching implementation when deserializing

by Scott Marlow (JIRA)

Create a SerializableValidatorFactory wrapper that has enough information to either access or create a matching implementation when deserializing ------------------------------------------------------------------------------------------------------------------------------------------------- Key: HV-460 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-460 Project: Hibernate Validator Issue Type: Improvement Components: validators Reporter: Scott Marlow -- 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

12 years, 7 months

3
18
0 / 0

[Hibernate-JIRA] Created: (HHH-3967) Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !!

by Guenther Demetz (JIRA)

Great performance improvement for CascadingAction.PERSIST_ON_FLUSH action !! ---------------------------------------------------------------------------- Key: HHH-3967 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3967 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: 3.3.1 GA , SQLServer Reporter: Guenther Demetz Sometimes large stateful transactions are unavoidable and especially when having several large persistent collections in dirty state, flushing becomes gradually more cpu intensive and slowly. Analizing several stacktraces I detected that the thread most time is executing at the same point in reflection , see here a typical stacktrace: java.lang.Class.isAssignableFrom(Native Method) sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:36) ... java.lang.reflect.Field.get(Field.java:358) DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:55) PojoEntityTuplizer(AbstractEntityTuplizer).getPropertyValue(Object, int) line: 300 SingleTableEntityPersister(AbstractEntityPersister).getPropertyValue(Object, int, EntityMode) line: 3609 Cascade.cascade(EntityPersister, Object, Object) line: 172 ... Making further investigations, I saw that: - CascadingAction.PERSIST_ON_FLUSH requires NoCascadeChecking - for all kind of properties the noCascade implementation is called - regarding noCascade implementation checks only properties of type Entity ! public static final CascadingAction PERSIST_ON_FLUSH = new CascadingAction() { ... public void noCascade(EventSource session, Object child, Object parent, EntityPersister persister, int propertyIndex) { ... Type type = persister.getPropertyTypes()[propertyIndex]; if ( type.isEntityType() ) { ... check and throw eventually a TransientObjectException } } Thus most property values are retrieved by reflection in vain as they are not of type entity. With following code addition in org.hibernate.engine.Cascade.java I was able do avoid most reflection method calls without affecting the behaviour: org.hibernate.engine.Cascade.java ... public void cascade(final EntityPersister persister, final Object parent, final Object anything) throws HibernateException { ... else if ( action.requiresNoCascadeChecking() ) { // Line:162 // begin Improvement if (action == CascadingAction.PERSIST_ON_FLUSH) { Type type = persister.getPropertyTypes()[i]; if ( !type.isEntityType() ) { // Remark: goes only well as long PERSIST_ON_FLUSH noCascade implementation checks only entities continue; } } // end Improvement action.noCascade( eventSource, persister.getPropertyValue( parent, i, entityMode ), parent, persister, i ); ... best regards Guenther D. -- 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

12 years, 8 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HHH-6039) jpaEntityName not set when using Hibernate mapping

by JOUFFRE Nelly (JIRA)

jpaEntityName not set when using Hibernate mapping -------------------------------------------------- Key: HHH-6039 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6039 Project: Hibernate Core Issue Type: Bug Components: metamodel, query-criteria Affects Versions: 3.6.2 Environment: hibernate-(core, entitymanager...)-3.6.2.Final hibernate-jpa-2.0-api-1.0.0.Final MySQL 5.1 Spring 3.0.5.RELEASE Reporter: JOUFFRE Nelly Attachments: Qualifier.hbm.xml I'm trying to run the following query CriteriaBuilder cb = entityManager.getCriteriaBuilder(); CriteriaQuery<Qualifier> cq = cb.createQuery(Qualifier.class); Root<Qualifier> qualifRoot = cq.from(Qualifier.class); List<Qualifier> results = entityManager.createQuery(cq).getResultList(); The Qualifier class is mapped using Hibernate hbm.xml mapping (see attachement) The entityManagerFactory is configured using a Spring class <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> ... </bean> This Criteria query throws the exception: org.hibernate.hql.ast.QuerySyntaxException: unexpected token: null near line 1, column 29 [select generatedAlias0 from null as generatedAlias0] The FROM clause, which here is null, is built using the EntityType.jpaEntityName property which value comes from PersistentClass.jpaEntityName property. But this property is never set when context is loaded to build the Metamodel. Is this property not set because the mapping is an hibernate mapping and not a JPA one ? or is it a bug ? -- 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

12 years, 8 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5191) CollectionMetadataGenerator fails to obtain mappedBy attribute when is defined on superclasses

by Hernán Chanfreau (JIRA)

CollectionMetadataGenerator fails to obtain mappedBy attribute when is defined on superclasses ---------------------------------------------------------------------------------------------- Key: HHH-5191 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5191 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.5.1 Environment: Hibernate-envers build from branch_3_5 (3.5.2-SNAPSHOT) Reporter: Hernán Chanfreau When the inverse side on a bidirectional relation is defined on a superclass, envers fails to configure the mappedBy attribute because it doesn't search on superclasses. Here is the original discussion: http://community.jboss.org/thread/151240?tstart=0 I'm attaching two patcher. One contains 2 test cases and another with some modifications for this. Regards. Hernán. -- 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

12 years, 8 months

5
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2011