March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-561) Determine and mark the API to be deprecated for HV5

by Hardy Ferentschik (JIRA)

Determine and mark the API to be deprecated for HV5 --------------------------------------------------- Key: HV-561 URL: https://hibernate.onjira.com/browse/HV-561 Project: Hibernate Validator Issue Type: Task Components: documentation, engine Affects Versions: 4.3.0.Alpha1 Reporter: Hardy Ferentschik Fix For: 4.3.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1065) Fuzzy search on Enums crash

by Sylvain Vieujot (JIRA)

Fuzzy search on Enums crash --------------------------- Key: HSEARCH-1065 URL: https://hibernate.onjira.com/browse/HSEARCH-1065 Project: Hibernate Search Issue Type: Bug Components: query Affects Versions: 4.1.0.CR2 Reporter: Sylvain Vieujot Attachments: com.seanergie.persistence.HibernateSearchTest.txt, HibernateSearchTest.java I get doing a fuzzy search on an Enum : query = ftem.getSearchFactory() .buildQueryBuilder() .forEntity( TestEntity.class ) .get() .keyword() .fuzzy() .onField( "testEnum" ) // CRASH HERE .matching( "TWO" ) .createQuery(); I get the following Exception : org.hibernate.search.bridge.BridgeException: Exception while calling bridge#objectToString class: com.seanergie.persistence.HibernateSearchTest$TestEntity path: testEnum at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper.buildBridgeException(ContextualExceptionBridgeHelper.java:97) at org.hibernate.search.bridge.util.impl.ContextualExceptionBridgeHelper$TwoWayConversionContextImpl.objectToString(ContextualExceptionBridgeHelper.java:149) at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.objectToString(DocumentBuilderIndexedEntity.java:370) at org.hibernate.search.engine.spi.DocumentBuilderIndexedEntity.objectToString(DocumentBuilderIndexedEntity.java:740) at org.hibernate.search.query.dsl.impl.ConnectedMultiFieldsTermQueryBuilder.buildSearchTerm(ConnectedMultiFieldsTermQueryBuilder.java:141) at org.hibernate.search.query.dsl.impl.ConnectedMultiFieldsTermQueryBuilder.createQuery(ConnectedMultiFieldsTermQueryBuilder.java:95) at org.hibernate.search.query.dsl.impl.ConnectedMultiFieldsTermQueryBuilder.createQuery(ConnectedMultiFieldsTermQueryBuilder.java:76) at com.seanergie.persistence.HibernateSearchTest.testFuzzySearchOnEnum(HibernateSearchTest.java:53) Code and full stack attached. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-6915) Restrictions.ilike(String propertyValue, Object value) does not correctly initialize LikeExpresison

by Martin Kartumovich (JIRA)

Restrictions.ilike(String propertyValue, Object value) does not correctly initialize LikeExpresison --------------------------------------------------------------------------------------------------- Key: HHH-6915 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6915 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.Final Reporter: Martin Kartumovich Priority: Minor The method Restrictions.ilike(String propertyValue, Object value) uses the LikeExpression-Constructor LikeExpression(propertyName, value.toString()) which will initialize the LikeExpression with "ignoreCase = false". The resulting SQL shows a normal "xyz like ?" instead of the expected "lower(xyz) like lower(?)" (i.e. Oracle10gDialect). This issue seems to have been introduced with HHH-4943. Workaround: Use Restrictions.ilike(String propertyValue, Object value, MatchMode mode). This will correctly initialize LikeExpression with "ignoreCase = true". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-7206) NaturalIdLoadAccess: NaturalId synchronization with no need to flush at all

by Guenther Demetz (JIRA)

NaturalIdLoadAccess: NaturalId synchronization with no need to flush at all --------------------------------------------------------------------------- Key: HHH-7206 URL: https://hibernate.onjira.com/browse/HHH-7206 Project: Hibernate ORM Issue Type: Improvement Components: core Affects Versions: 4.1.1 Environment: Hibernate4, database-independent Reporter: Guenther Demetz With few code changes I think it is possible to make NaturalIdLoadAccess work with no need to rely on flush at all, please see following comments. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
35
0 / 0

[Hibernate-JIRA] Created: (HHH-6556) Bind unsaved value for identifier/version property

by Strong Liu (JIRA)

Bind unsaved value for identifier/version property -------------------------------------------------- Key: HHH-6556 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6556 Project: Hibernate Core Issue Type: Task Components: metamodel Reporter: Strong Liu Fix For: 4.0.0.next currently org.hibernate.metamodel.binding.KeyValueBinding#getUnsavedValue is not binded -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-979) Programmatic API: mapping a composite primary key

by Fuessmann (JIRA)

Programmatic API: mapping a composite primary key ------------------------------------------------- Key: HSEARCH-979 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-979 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 3.4.1.Final, 3.3.0.Final Environment: Hibernate 3.6 Final Reporter: Fuessmann Hallo, I'm using Hibernate Search in combination with the [b]Programmatic API[/b] for dynamic indexing. Is there any possibility to index an entity with an composite primary key annotated with [b]@EmbeddedId[/b]. Using H.Search without the Programmatic API i choose a TwoWayFieldBridge but how can I use it with the Programmatic API? In my case I am trying to implement a programmatic mapping for an entity. The entity has an an composite primary key annotated with @EmbeddedId. {quote} ... @Entity(name = "a") @Table(name = "a") public class A implements java.io.Serializable { ... @EmbeddedId @AttributeOverrides( { @AttributeOverride(name = "name_1", column = @Column(name = "name_1", nullable = false, length = 64)), @AttributeOverride(name = "name_2", column = @Column(name = "name_2", nullable = false, length = 16)) }) public AId getId() { return this.id; ... } {quote} Code for ABridge.class is not shown but still exists .. I try a code like this, but the code does not work: {quote} mapping.entity(A.class).indexed().indexName("a") .property("id", ElementType.METHOD).documentId().field().bridge(ABridge.class) {quote} Exception occurred during event dispatching: {quote} org.hibernate.HibernateException: [color=#FF0000]could not init listeners{color} ... Caused by: org.hibernate.search.SearchException: {color:red} Unable to guess FieldBridge for id{color} ... {quote} I need an advise to solve my problem. Thanks -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

4
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7072) ElementCollection not updated correctly if the Embeddable component has a nullable property

by Aaron Trewern (JIRA)

ElementCollection not updated correctly if the Embeddable component has a nullable property ------------------------------------------------------------------------------------------- Key: HHH-7072 URL: https://hibernate.onjira.com/browse/HHH-7072 Project: Hibernate ORM Issue Type: Bug Components: annotations Affects Versions: 3.5.2 Reporter: Aaron Trewern I have an @ElementCollection that is a collection of @Embeddable components. When saving an updated entity I can see that Hibernate issues an SQL DELETE for each of the rows in the collection followed by an INSERT, as is expected behaviour for an @ElementCollection. The rows are deleted using a where clause that includes all the properties of the @Embeddabkle component. With MySQL the DELETE fails to delete any rows where the property is a nullable property and the previous value was null. This is because Hibernate issues a prepared SQL ststement like "DELETE FROM tableName t where t.a = ? and t.b = ?" now if b is a nullable property and the component being saved has a null value for b then the delete will fail. To correctly delete the row with MySQL the statement should be "DELETE FROM tableName t where t.a = ? and t.b is null" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-564) Allow caching of ConstraintValidator instances also for custom ConstraintValidatorFactories

by Hardy Ferentschik (JIRA)

Allow caching of ConstraintValidator instances also for custom ConstraintValidatorFactories ------------------------------------------------------------------------------------------- Key: HV-564 URL: https://hibernate.onjira.com/browse/HV-564 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.3.0.Alpha1 Reporter: Hardy Ferentschik Fix For: 4.3.0.Beta1 See also http://soularis999.blogspot.de/2011/07/bean-validation-performance-evalua... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7179) impl natural id region in hibernate-infinispan

by Strong Liu (JIRA)

impl natural id region in hibernate-infinispan ---------------------------------------------- Key: HHH-7179 URL: https://hibernate.onjira.com/browse/HHH-7179 Project: Hibernate ORM Issue Type: Improvement Components: caching (L2) Reporter: Strong Liu Fix For: 4.1.2 HHH-6974 introduced new natural id 2L cache api, we need to impl it in hibernate-infinispan -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
3
0 / 0

[Hibernate-JIRA] Created: (METAGEN-86) Generator exits when discovering <xml-mapping-metadata-complete/> in ANY persistence unit

by Christian Bauer (JIRA)

Generator exits when discovering <xml-mapping-metadata-complete/> in ANY persistence unit ----------------------------------------------------------------------------------------- Key: METAGEN-86 URL: https://hibernate.onjira.com/browse/METAGEN-86 Project: Hibernate Metamodel Generator Issue Type: Bug Affects Versions: 1.2.0.Final Reporter: Christian Bauer Assignee: Hardy Ferentschik Priority: Minor I have several persistence units in persistence.xml, one of them uses <xml-mapping-metadata-complete/>. As soon as the metamodel generator discovers this unit, it stops processing any other persistence unit in the peristence.xml. Probably related to https://hibernate.onjira.com/browse/METAGEN-7 Workaround is ignoring persistence.xml: fullyAnnotationConfigured=true -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years

2
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2012