March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-517) Establish the notion of AnnotationIgnores for programmatic API

by Gunnar Morling (JIRA)

Establish the notion of AnnotationIgnores for programmatic API -------------------------------------------------------------- Key: HV-517 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-517 Project: Hibernate Validator Issue Type: Improvement Components: engine Reporter: Gunnar Morling Fix For: 4.3.0.next Using the programmatic constraint API, it should be possible to exclude annotation configured constraints in the same manner as possible with the {{ignore-annotions}} attribute in XML descriptors. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7202) No warning when declared targetEntity class doesn't match type of property

by Alex Cruise (JIRA)

No warning when declared targetEntity class doesn't match type of property -------------------------------------------------------------------------- Key: HHH-7202 URL: https://hibernate.onjira.com/browse/HHH-7202 Project: Hibernate ORM Issue Type: Bug Components: entity-manager Affects Versions: 4.1.1 Reporter: Alex Cruise I had a mapping error like this: @ManyToOne(targetEntity=Foo.class, fetch=FetchType.EAGER) Bar bar; The evidence for the error wound up being low-level and far removed: java.lang.Exception: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of Foo.id If there's any way that these correspondences could be validated earlier, it would be nice! Specifically, the type of the property should be assignable from the annotation's targetEntity class (or is it the opposite? I seem to be incapable of remembering which direction isAssignableFrom goes.) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6895) Easier annotation definitiopn of increment generator

by Steve Ebersole (JIRA)

Easier annotation definitiopn of increment generator ---------------------------------------------------- Key: HHH-6895 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6895 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Priority: Minor Fix For: 4.1.0 Useful in tests at least. Lot of duplication to specify an increment generator currently: {code} @Id @GeneratedValue( generator="increment" ) @org.hibernate.annotations.GenericGenerator( name = "increment", strategy = "increment" ) public Long getId() { .. } {code} Combined with the fact that the increment generator does not accept configuration, would be nice to be able to just say: {code} @Id @GeneratedValue( generator="increment" ) public Long getId() { .. } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7183) Bind HibernateTypeDescriptor fields once

by Gail Badner (JIRA)

Bind HibernateTypeDescriptor fields once ---------------------------------------- Key: HHH-7183 URL: https://hibernate.onjira.com/browse/HHH-7183 Project: Hibernate ORM Issue Type: Task Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 5.0.0 HibernateTypeDescriptor Fields can be initialized by HibernateTypeHelper and in Binder. The fix will make the Binder responsible for deciding the precedence when there is more than one possible setting (e.g., from a type="..." mapping vs reflection vs a default). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-563) Enable Configuration#buildValidatorFactory() to be callable several times

by Gunnar Morling (JIRA)

Enable Configuration#buildValidatorFactory() to be callable several times ------------------------------------------------------------------------- Key: HV-563 URL: https://hibernate.onjira.com/browse/HV-563 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0.Final Reporter: Gunnar Morling Fix For: 4.3.0.Beta1 Currently invoking {{buildValidatorFactory}} several times on one {{Configuration}} instance results in an NPE. While the spec currently doesn't clearly say whether invoking {{buildValidatorFactory}} more than once is legal or not, I personally think we should support that use case. Original HV forum post: https://forum.hibernate.org/viewtopic.php?f=9&t=1014788 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1078) Dirty checking fails when searchable annotations are used on getter with 'non-standard' name

by Elmer van Chastelet (JIRA)

Dirty checking fails when searchable annotations are used on getter with 'non-standard' name -------------------------------------------------------------------------------------------- Key: HSEARCH-1078 URL: https://hibernate.onjira.com/browse/HSEARCH-1078 Project: Hibernate Search Issue Type: Bug Components: mapping Affects Versions: 4.1.0.CR2, 3.4.2 Reporter: Elmer van Chastelet Attachments: TestEntityChangeWithDifferentGetterName.zip A new issue, more detailed, as suggested in [HSEARCH-1076|https://hibernate.onjira.com/browse/HSEARCH-1076]. Hibernate search propagates entity changes to the search index(es) during an OnPostUpdate event. It checks if dirty properties are searchable, and if at least one dirty property is searchable, it builds a new document, replacing the one already in the index(es). The 'checks if dirty properties are searchable'-part is currently failing when the following prerequisites are met: - There is a java field F with getter method. e.g. private string _text; - The getter method differs from the standard naming convention (e.g. getText for the field _text) - The searchable annotation is placed on the getter method - An entity is changed, where field F has a new value (e.g. _text is a dirty property). It fails because it checks by using the meta data classes XClass and XProperty, and it uses XClass.getDeclaredProperties( XClass.ACCESS_PROPERTY ) to initially retrieve the names of the searchable entity properties (which are put in org.hibernate.search.engine.AbstractDocumentBuilder.PropertiesMetadata.fieldNameToPositionMap). The problem is that XClass.getDeclaredProperties( XClass.ACCESS_PROPERTY ) returns the name extracted from the getter's method name. For the field _text used above, this means that dirty property '_text' is not linked to the extracted getter's method name 'text', and thus will not trigger a change to the search index(es). This issue is in some form related to [HHH-775|https://hibernate.onjira.com/browse/HHH-755], stating that getters should comply with JavaBeans spec 1.01. This specification says in section 7.1: {quote} GetFoo and setFoo are simply example names. Accessor methods can have arbitrary names. However for standard naming conventions for accessor methods see the design patterns de- scribed in Section 8.3. {quote} So it doesn't force us to use the standard naming convention and I would argue that accessor methods may carry any name. (another example is the getter for a boolean flag, which is often in the form isEnabled()) Attached is a test case illustrating the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7200) SessionFactoryObservers should be notified of the close event in reverse order of the create event

by Emmanuel Bernard (JIRA)

SessionFactoryObservers should be notified of the close event in reverse order of the create event -------------------------------------------------------------------------------------------------- Key: HHH-7200 URL: https://hibernate.onjira.com/browse/HHH-7200 Project: Hibernate ORM Issue Type: Bug Reporter: Emmanuel Bernard Priority: Minor to follows the interceptor pattern. Each observer would be able to undo its work before the previous one kicks in. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1076) Simple entity changes not reflected in index

by Elmer van Chastelet (JIRA)

Simple entity changes not reflected in index -------------------------------------------- Key: HSEARCH-1076 URL: https://hibernate.onjira.com/browse/HSEARCH-1076 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 4.1.0.CR2, 3.4.2 Environment: Unit test on Ubuntu 11.10 x64 Reporter: Elmer van Chastelet I was unable to find a unit test which tests if an entity change on a searchable String field (probably also other types) is reflected in the index. That's probably the reason I came across this serious issue. I have changed an existing test to see if my expectations were true, and indeed: solely changing a String property (searchable) of an entity won't trigger an update to the index. I will add a unit test for this particular case. For now, the failing code from an altered existing test: {code:title=snippet from altered NestedEmbeddedTest.java} s.clear(); tx = s.beginTransaction(); product = ( Product ) s.get( Product.class, product.getId() ); product.setNwField("value1"); tx.commit(); s.clear(); session = Search.getFullTextSession( s ); tx = s.beginTransaction(); QueryParser parser2 = new QueryParser( TestConstants.getTargetLuceneVersion(), "nwField", TestConstants.standardAnalyzer ); query = parser2.parse( "value1" ); result = session.createFullTextQuery( query, Product.class ).list(); assertEquals( "change on simple string field not reflected in root index", 1, result.size() ); tx.commit(); {code} {code:title=addition to Product.java} @Field(store = Store.YES) private String nwField; public String getNwField(){ return nwField; } public void setNwField(String fld){ nwField = fld; } {code} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HBX-1200) hbm2ddl tool generates multiple foreign keys while mapping a collection of a class/ interface whose hierarchy is mapped using single_table strategy.

by Luca Pedriali (JIRA)

hbm2ddl tool generates multiple foreign keys while mapping a collection of a class/ interface whose hierarchy is mapped using single_table strategy. ---------------------------------------------------------------------------------------------------------------------------------------------------- Key: HBX-1200 URL: https://hibernate.onjira.com/browse/HBX-1200 Project: Hibernate Tools Issue Type: Bug Components: hbm2doc Environment: Hibernate version: 3.6.0.Final Database: Oracle 10G Reporter: Luca Pedriali Referring to this issue: https://hibernate.onjira.com/browse/HBX-494 , I found a similar problem. Mapping bidirectional ManyToOne relationships to classes of a single_table hierarchy, hbm2ddl generates multiple foreign keys of the same table. For now the only solution is to manually delete the extra foreign keys. Moreover, the solution proposed in the quoted jira (use the foreign-key property) is not applicable for me, because I use hibernate tool with an ant task and my code use only the JPA annotations. Appreciate if we could get a fix or workaround for the same. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 4 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-4699) String mapped ENUMs can't be loaded from CHARs only VARCHARS (fix is trivial)

by Pierce Wetter (JIRA)

String mapped ENUMs can't be loaded from CHARs only VARCHARS (fix is trivial) ----------------------------------------------------------------------------- Key: HHH-4699 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4699 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5 Environment: all Reporter: Pierce Wetter An enum persisted as a string to a CHAR column comes back with extra spaces appended, so then fails the Enum.valueOf() lookup. Fix is easy: Line 132 of EnumType.java, method nullSafeGet, change: return Enum.valueOf( enumClass, name ); to return Enum.valueOf( enumClass, name.trim() ); Which should be perfectly logical, because spaces are illegal in enum names anyways. -- 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, 4 months

4
7
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