March 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-197) validation of a persisted map

by tho gau (JIRA)

validation of a persisted map ----------------------------- Key: BVAL-197 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-197 Project: Bean Validation Issue Type: Bug Environment: hibernate-core 3.5.0-Beta-3 Validator 4.0.1.GA MySQL 5.1 Reporter: tho gau Attachments: mapValidation.zip Hi, I am trying to validate an entity that holds a Map<K, V> of other persisted entities (just checking wether the map holds some predefined values). I can validate it "by hand" using validator.validate() and my map is correctly filled at validation time However when validation framework is called by persistence callbacks, my map is always empty... I am using Validator 4.0.1.GA and hibernate-core 3.5.0-Beta-2 I tryed to pinpoint the problem and it seems that the map is not touched in the following method of AbstractType during the merge : {code} public Object replace( Object original, Object target, SessionImplementor session, Object owner, Map copyCache, ForeignKeyDirection foreignKeyDirection) throws HibernateException { boolean include; if ( isAssociationType() ) { AssociationType atype = (AssociationType) this; include = atype.getForeignKeyDirection()==foreignKeyDirection; } else { include = ForeignKeyDirection.FOREIGN_KEY_FROM_PARENT==foreignKeyDirection; } return include ? replace(original, target, session, owner, copyCache) : target; } {code} -- 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, 10 months

4
14
0 / 0

[Hibernate-JIRA] Created: (BVAL-278) Follow up on remaining todos for method-level validation

by Emmanuel Bernard (JIRA)

Follow up on remaining todos for method-level validation -------------------------------------------------------- Key: BVAL-278 URL: https://hibernate.onjira.com/browse/BVAL-278 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1 early draft 1 Reporter: Emmanuel Bernard Assignee: Gunnar Morling Fix For: 1.1 List the questions to follow up on and then follow up on them :) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-242) Extend the meta-data API to represent method-level constraints

by Gunnar Morling (JIRA)

Extend the meta-data API to represent method-level constraints -------------------------------------------------------------- Key: BVAL-242 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-242 Project: Bean Validation Issue Type: Sub-task Components: spec-general Reporter: Gunnar Morling Fix For: 1.1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-243) Provide a means for specifying method parameter names

by Gunnar Morling (JIRA)

Provide a means for specifying method parameter names ----------------------------------------------------- Key: BVAL-243 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-243 Project: Bean Validation Issue Type: Sub-task Reporter: Gunnar Morling Emmanuel wrote: {quote} On named parameters we have three strategies I think: - not address the problem at all and use positional parameters to see what comes up JDK 8's hat (named parameters might not be represented as strings but rather as a typed object) - not address the problem in the specification but leave the API open enough for a provider to offer a named parameter friendly API - address the problem within the spec (the interface approach seems elegant) hoping for the named parameter to be represented as a String in JDK 8 I tend to like param0, param1 etc rather than arg0, arg1 but that's aesthetic. {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

3
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-244) Extend Validator API with methods for method validation

by Gunnar Morling (JIRA)

Extend Validator API with methods for method validation ------------------------------------------------------- Key: BVAL-244 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-244 Project: Bean Validation Issue Type: Sub-task Components: spec-general Reporter: Gunnar Morling Fix For: 1.1 {{javax.validation.Validator}} needs additional methods for method validation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-245) Define how method constraints are declared at parameters and return values

by Gunnar Morling (JIRA)

Define how method constraints are declared at parameters and return values -------------------------------------------------------------------------- Key: BVAL-245 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-245 Project: Bean Validation Issue Type: Sub-task Components: spec-general Reporter: Gunnar Morling Fix For: 1.1 Emmanuel: {quote} Constraints on parameters whose type is a subtype of the accepted types by the constraint are declared directly on the parameter void doHarm(@NotEmpty String kittenName); Constrains on parameters whose type is a constrained bean needs an annotation accepting the targeted groups. It was proposed to use @Valid for such case but [recent discussions|https://hibernate.onjira.com/browse/BVAL-208?focusedCommentId...] brought that back on the drawing board. There are a few notions floating around @Valid 1. cascade validation to nested beans 2. translate the validation of group A from the owning bean to validation of the group B on the nested bean (see BVAL-208) 3. define the group to validate in a method level validation About 3., I wonder if this should be part of Bean Validation or be part of the interception framework. In other words: * should it be an annotation provided / proposed by Bean Validation and recognized by interception techs like CDI, @Inject, Spring, AspectJ etc * should each interception tech provide its own annotation to specify the targeted group(s) {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1061) Upgrade integration test to use JBoss AS 7.1.1

by Sanne Grinovero (JIRA)

Upgrade integration test to use JBoss AS 7.1.1 ---------------------------------------------- Key: HSEARCH-1061 URL: https://hibernate.onjira.com/browse/HSEARCH-1061 Project: Hibernate Search Issue Type: Task Components: tests Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Trivial Fix For: 4.1.0.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1058) Upgrade to Infinispan 5.1.1.FINAL and JGroups 3.0.6.Final

by Sanne Grinovero (JIRA)

Upgrade to Infinispan 5.1.1.FINAL and JGroups 3.0.6.Final --------------------------------------------------------- Key: HSEARCH-1058 URL: https://hibernate.onjira.com/browse/HSEARCH-1058 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1.0.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5419) COUNT operator with composite primary key and JPA 2.0 Criteria API produces bad sql

by Fabio Braga de Oliveira (JIRA)

COUNT operator with composite primary key and JPA 2.0 Criteria API produces bad sql ----------------------------------------------------------------------------------- Key: HHH-5419 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5419 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0.Beta1, 3.5.4, 3.5.3, 3.5.2, 3.5.1 Environment: hibernate-entitymanager 3.6.0.Beta1, glassfish 3.0.1, linux ubuntu 10.04, MS SQL Server 2008 Reporter: Fabio Braga de Oliveira Attachments: hibernate-count-bug.zip Hibernate produces a invalid SQL if anyone use the count() operator with the JPA 2.0 Criteria API. Code: CriteriaBuilder cb = getEntityManager().getCriteriaBuilder(); CriteriaQuery<Object[]> cq = cb.createQuery(Object[].class); Root<EntityCompositePK> r = cq.from(EntityCompositePK.class); cq.multiselect(cb.count(r)); assertEquals(0, ((Long) (getEntityManager().createQuery(cq).getSingleResult())[0]).intValue()); I'm sending a little maven project which reproduces the 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, 10 months

8
17
0 / 0

[Hibernate-JIRA] Commented: (HHH-1097) No way to access directly access UserType in Interceptor

by Tom Coogan (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1097?page=com.atlassian.jira.plug... ] Tom Coogan commented on HHH-1097: --------------------------------- The proposed solution appears to have been implemented in the commit for HHH-4443: https://github.com/hibernate/hibernate-orm/commit/9e76e1b184bce54f94f7442... > No way to access directly access UserType in Interceptor > -------------------------------------------------------- > > Key: HHH-1097 > URL: https://hibernate.onjira.com/browse/HHH-1097 > Project: Hibernate ORM > Issue Type: Improvement > Affects Versions: 3.1 rc 1 > Environment: 3.1rc1, DB2 400, JDK 1.4.2_09 > Reporter: James Schopp > Priority: Minor > > In my custom Interceptor, I cannot access my custom UserType directly. This also has the result that the only way to determine if a field is of my UserType is by doing a string comparison: if would prefer to do "instanceof" sing this looks nice and runs faster. More detail: > The methods of interface "Interceptor" receive an array of interface "Type". > For any properties/columns that are mapped using a UserType, the "type" received in the Interceptor method is actually a "CustomType" object that wraps (delegation) the UserType and implements the "Type" interface. There is no way to actually access the underlying UserType (that I know is there!) > Finally, since there is no way to access the UserType, the only way to determine what "type" is really under all those layers is by doing types[i].getName() and then doing a string comparison against MyUserType.getClass().getName(). This is very ugly, and quite slow compared to the "instanceof" that I would like to do instead. > And finally again, the REASON that I need to access my UserType in my Interceptor is so that the Interceptor can call an "interface" method on my UserType, and my UserType will go off an do a specific action (depending on whether it really represents a String, or Date, etc...) Currently, I must have a huge if-else-if-else block based on String comparisons that dispatch method calls depending on the type detected. The cleaner way would be to see if the type is an instance of "my" interface, and if so, call an interface method on it. > Possible Solution > ================= > Just add a new method to org.hibernate.type.CustomType which is/would be: > public UserType getUserType() { return userType; } > Then from the Interceptor, you could do: > if (types[i] instanceof CustomType) { > CustomType ct = (CustomType) types[i]; > if (ct.getUserType instanceof MyOwnUserType) { > ....... > } > } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2012