February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-234) Netbeans 7 default generated entity classes conflict with bean validation

by Richard Clarke (JIRA)

Netbeans 7 default generated entity classes conflict with bean validation -------------------------------------------------------------------------- Key: BVAL-234 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-234 Project: Bean Validation Issue Type: Improvement Components: spec-general Affects Versions: 1.1 Environment: Netbeans 7, Seam 3 under JBOSS AS 7 Reporter: Richard Clarke Priority: Minor When using NetBeans 7 to generate entity classes from a database table, the entity classes are generated with the following annotations... public class Orders implements Serializable { private static final long serialVersionUID = 1L; @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Basic(optional = false) @NotNull @Column(name = "orderid") private Integer orderid; ..... When persisting, bean validation fails because the autogenerated primary key is null at the time the object is persisted. Netbeans have stated that they wont fix this as they see it as bean validation issue rather than their generated classes. See here: http://netbeans.org/bugzilla/show_bug.cgi?id=197845 Related Forum posting is here... https://forum.hibernate.org/viewtopic.php?f=9&t=1011908 Suggest modifying Bean Validation Pre-Persist to ignore @NotNull if @GeneratedValue exists. Thanks Rich -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

4
9
0 / 0

[Hibernate-JIRA] Created: (BVAL-248) Introduce order for propery constraints and allow to stop validation for first failing property constraint

by Hardy Ferentschik (JIRA)

Introduce order for propery constraints and allow to stop validation for first failing property constraint ---------------------------------------------------------------------------------------------------------- Key: BVAL-248 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-248 Project: Bean Validation Issue Type: New Feature Components: spec-general Affects Versions: 1.0 final Reporter: Hardy Ferentschik Atm it is very cumbersome to specify multiple constraint per property and stop validation (on a property level) for the first failing constraint. See also HV-462 Since the Java reflection API does not allow to reflect on the order of the specified constraints you would need to introduce an _order_ property for the constraints or some additional annotation. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-462) Allow ordered validator's annotations

by Pavla Nováková (JIRA)

Allow ordered validator's annotations ------------------------------------- Key: HV-462 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-462 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 4.1.0.Final Reporter: Pavla Nováková 1) Consider domain object with simple constraints (just to demonstrate required feature, my real example uses custom cost-expensive validation of pictures): {code} public class DomainObject { @Size(max=50) // constraint 1a @Pattern(regexp="[a-z]*") // constraint 1b private String name; @Size(max=20) // constraint 2a @URL // constraint 2b private String email; @Size(max=100) // constraint 3a @Pattern(regexp="[0-9]*") // constraint 3b private String password; {code} 2) Consider validation requirements: * all properties should be validated together (like one virtual group) * FOR EACH PROPERTY validation should occur in ordered steps given by order of annotations for given property (if first validation step fails, SKIP following validation process on given property and add validation message specific to failed / last validated constraint for the property) 3) Why it is useful: * simple cost-effective validation followed by cost-expensive validation (not executed if simple constraint fails) * we get just the "main and specific validation error" (otherwise we have to iterate over all errors "to find the cause" or we display two or more errors for one property which is not user-friendly according my opinion) 3) What is unusable: * groups and group sequences (it is not possible to create proper combination of groups and sequences for more than one property with two or more constraints) * composed constraints (@ReportAsSingleViolation included) ** we cannot use @ReportAsSingleViolation since we want specific message for each failed constraint ** and main problem is: if we use composed constraints all constraints are evaluated for given property 4) Proposed solution: * add optional order attribute to validator annotations and stop validation on first failure if order is specified * possibly this can be configured on global validator level with property "skipOnFirstFailure" together with some given convention for annotation order Please let me know if need better explanation or working examples. -- 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

11 years, 2 months

3
8
0 / 0

[Hibernate-JIRA] Created: (BVAL-255) Simplify GroupSequence for ordered checking

by Cemo Koc (JIRA)

Simplify GroupSequence for ordered checking ------------------------------------------- Key: BVAL-255 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-255 Project: Bean Validation Issue Type: New Feature Components: spec-general Affects Versions: 1.0 final Reporter: Cemo Koc The JSR 303 is becoming defacto solution at enterprise level projects however I think that it has a significant useless part. The current implementation states group sequence must be utilized to ordered validation. In order to use group sequence, one has to define interfaces for each order sequence such this: {code} public class AccountBean { @CheapValidation(groups=Name1.class) @ExpensiveValidation(groups=Name2.class) @VeryExpensiveValidation(groups=Name3.class) String name; @CheapValidation(groups=Surname1.class) @ExpensiveValidation(groups=Surname2.class) @VeryExpensiveValidation(groups=Surname3.class) String surname; public interface Name1 {} public interface Name2 {} public interface Name3 {} @GroupSequence({Name1.class, Name2.class, Name3.class}) public interface Name {} public interface Surname1 {} public interface Surname2 {} public interface Surname3 {} @GroupSequence({Surname1.class, Surname2.class, Surname3.class}) public interface Surname {} } {code} Look the code how it is ugly and useless. What I am offering is a simplified version of ordering such this: {code} public class AccountBean { @CheapValidation(order=0,groups=Name1.class) @ExpensiveValidation(order=1,groups=Name2.class) @VeryExpensiveValidation(order=2,groups=Name3.class) String name; @CheapValidation(order=0,groups=Surname1.class) @ExpensiveValidation(order=1,groups=Surname2.class) @VeryExpensiveValidation(order=2,groups=Surname3.class) String surname; } {code} Almost all enterprise projects needs such kind of things. For example lets say that you want to validate email field by NotEmpty and UniqueAtDatabase. Why should we show two error messages in this case? Shortly, to increase usability and adaptability please solve this issue. PS: This issue is cross posted here and forums. https://forum.hibernate.org/viewtopic.php?f=26&t=1007328 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

2
1
0 / 0

[Hibernate-JIRA] Created: (BVAL-261) Let composed constraint return the message of the first failing constraint instead of the composed constraint

by Emmanuel Bernard (JIRA)

Let composed constraint return the message of the first failing constraint instead of the composed constraint ------------------------------------------------------------------------------------------------------------- Key: BVAL-261 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-261 Project: Bean Validation Issue Type: Improvement Reporter: Emmanuel Bernard A better name is needed but to get the idea @ReportAsSingleViolation(messageSource=ByOriginatingConstraint) This would return the composing constraint message (say from @Size) instead of the composed constraint @ZipCode -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-555) Improve toString() in ConstraintViolationException

by David J. M. Karlsen (JIRA)

Improve toString() in ConstraintViolationException -------------------------------------------------- Key: HV-555 URL: https://hibernate.onjira.com/browse/HV-555 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.2.0.Final Environment: N/A Reporter: David J. M. Karlsen It would be nice if the mesage from ConstraintViolationException was better so that when logging it would show the beanpath and errors by default. Today it will just read: {noformat} javax.validation.ConstraintViolationException: null {noformat} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (BVAL-267) Provide a ConstraintViolationException builder to facilitate consumer code

by Emmanuel Bernard (JIRA)

Provide a ConstraintViolationException builder to facilitate consumer code -------------------------------------------------------------------------- Key: BVAL-267 URL: https://hibernate.onjira.com/browse/BVAL-267 Project: Bean Validation Issue Type: Improvement Components: spec-general Reporter: Emmanuel Bernard -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7000) Avoid initializing proxy when using covariant return types for ID getters

by Michael Rudolf (JIRA)

Avoid initializing proxy when using covariant return types for ID getters ------------------------------------------------------------------------- Key: HHH-7000 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-7000 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Michael Rudolf When using an entity hierarchy with overridden ID getters and covariant return types, Hibernate does not detect ID getter calls and unnecessarily initializes proxies in order to call the methods instead of just returing the ID. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3502) getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type

by Sean Bridges (JIRA)

getIdentifierMethod of BasicLazyInitializer does not match if method invoked through an interface with different return type ---------------------------------------------------------------------------------------------------------------------------- Key: HHH-3502 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3502 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Reporter: Sean Bridges Priority: Minor I have an entity interface, public interface IEntity { public Object getId(); } and I have an entity, say User that implements this interface with an id method @Id public Long getId() { return id; } I can call getId() on an uninitialized proxy with, user.getId() however, if I call getId() in this way, ((IEntity) user)).getId() I get org.hibernate.LazyInitializationException: could not initialize proxy - no Session Looking at the code, BasicLazyInitializer has these lines, else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } the method.equals(getIdentifierMethod) returns false. The methods are not equal() because they have different return types (this is allowed in 1.5 with covariant return types). Hibernate should not use Method.equals(), but should instead use the code below (modified from Method.equals(Object)), public boolean equalsIgnoringReturnType(Method m1, Method m2) { if ((m1.getDeclaringClass() != m2.getDeclaringClass()) { return false; } if (m1.getName() != m2.getName()) { return false; } Class[] params1 = m1.getParameterTypes(); Class[] params2 = m2.getParameterTypes(); if (params1.length != params2.length) { return false; } for (int i = 0; i < params1.length; i++) { if (params1[i] != params2[i]) return false; } return true; } -- 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

11 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (JPA-12) Cannot use { in string literal of native SQL query

by Neil Buesing (JIRA)

Cannot use { in string literal of native SQL query -------------------------------------------------- Key: JPA-12 URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-12 Project: Java Persistence API Issue Type: Bug Affects Versions: 1.0.0 Environment: Hibernate 3.3.2.GA_CP01, Oracle 10g, Windows 32bit, Java 1.6 Reporter: Neil Buesing a JPA Native query will throw an exception if a { is within a string literal. Rejected Hibernate Defect: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2744 Exception: Caused by: java.lang.IllegalArgumentException: org.hibernate.QueryException: Unmatched braces for alias path Query example (taken from HHH-2744) select count(distinct v.id) from some_table v left join other_table p on v.id = p.foreign_id where upper(v.last_name) like upper('{%'); No where do I find in the JPA specification that SQL queries can be limited; if the SQL is valid, it should be able to be parsed by the JPA Native Query support. I understand there is a work around, but it should be allowed. The {} balance check shouldn't count {} that are within string literals. -- 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

11 years, 2 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2012