October 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5291) Hibernate generates several join clauses for same table

by Igor Nikolaev (JIRA)

Hibernate generates several join clauses for same table ------------------------------------------------------- Key: HHH-5291 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5291 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.2 Environment: Hibernate 3.5.2 Reporter: Igor Nikolaev Suppose you've got a mapping: <class name="Class" table="TABLE1" dynamic-update="true"> <id name="id" type="int"> <column name="ID" /> <generator class="assigned" /> </id> <discriminator column="CLASS_TYPE"/> <property name="property1" type="string" column="PROPERTY1" update="false" insert="false"/> <join table="TABLE2" optional="true"> <key column="ID" not-null="false"/> <property name="property2" column="PROPERTY2"/> </join> <subclass name="Subclass" discriminator-value="SUBCLASS"> <join table="TABLE2"> <key column="swift_id"/> <property name="property3" column="PROPERTY3"/> </join> </subclass> </class> As you can notice, we join the same table in subclass. Expected result is that Hibernat generates a query like this one: select this_.ID, this_.PROPERTY1, this_1_.PROPERTY2, this_1_.PROPERTY3 from TABLE1 this_ left inner join TABLE2 this_1_ on this_.ID=this_1_.ID Instead, Hibernate joins TABLE2 twice and generates the following query: select this_.ID, this_.PROPERTY1, this_1_.PROPERTY2, this_2_.PROPERTY3 from TABLE1 this_ left inner join TABLE2 this_1_ on this_.ID=this_1_.ID left outer join TABLE2 this_2_ on this_.ID=this_2_.ID -- 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, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6271) deploying with a 1.0 orm.xml, gets unexpected error HHH00196:Error parsing XML (2) : cvc-complex-type.3.1: Value '1.0' of attribute 'version' of element 'entity-mappings' is not valid with respect to the corresponding attribute use. Attribute 'version' ha

by Scott Marlow (JIRA)

deploying with a 1.0 orm.xml, gets unexpected error HHH00196:Error parsing XML (2) : cvc-complex-type.3.1: Value '1.0' of attribute 'version' of element 'entity-mappings' is not valid with respect to the corresponding attribute use. Attribute 'version' ha --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-6271 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6271 Project: Hibernate Core Issue Type: Bug Components: entity-manager Reporter: Scott Marlow Fix For: 4.0.0.Beta1 -- 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, 1 month

4
19
0 / 0

[Hibernate-JIRA] Created: (HV-264) Validation of List of primitives

by Michenaud Laurent (JIRA)

Validation of List of primitives -------------------------------- Key: HV-264 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-264 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.0.1 Environment: Linux Reporter: Michenaud Laurent Hi, I have a list of String in my bean : These strings are email and i want to validate them. So, i did in my bean : @NotEmpty @Email //@Valid <= uncommenting that line doesnot change anything. List<String> emails ; At execution, i've got the error : Exception in thread "main" javax.validation.UnexpectedTypeException: No validator could be found for type: java.util.List<java.lang.String> at org.hibernate.validator.engine.ConstraintTree.verifyResolveWasUnique(ConstraintTree.java:236) at org.hibernate.validator.engine.ConstraintTree.findMatchingValidatorClass(ConstraintTree.java:219) at org.hibernate.validator.engine.ConstraintTree.getInitializedValidator(ConstraintTree.java:167) at org.hibernate.validator.engine.ConstraintTree.validateConstraints(ConstraintTree.java:113) at org.hibernate.validator.metadata.MetaConstraint.validateConstraint(MetaConstraint.java:121) at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:334) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:278) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:260) at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:213) at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:119) at com.adeuza.movalys.validation.hibernate.TestMain.main(TestMain.java:75) I don't know if it is a bug in hibernate validator. I have looked at the JSR303 and i have not seen anything about List of primitives. You can validate per example List<Person> with @Valid and it works well because the validator knows about Person class. I have used a little the Oval framework and with it, you can tell if the check applies to the container, or the values inside, or the keys(for map). I don't know if you can do that with JSR303. I'm interesting with your point of view. -- 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, 1 month

3
12
0 / 0

[Hibernate-JIRA] Created: (HV-270) Verify in the annotation processor that constraints are not stupid

by Emmanuel Bernard (JIRA)

Verify in the annotation processor that constraints are not stupid ------------------------------------------------------------------ Key: HV-270 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-270 Project: Hibernate Validator Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik For example @Pattern shoudl ahve a valid regular exception @Size should have min <= max etc -- 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, 1 month

3
10
0 / 0

[Hibernate-JIRA] Created: (HV-135) Constraints can contains constraint annotations to validate params before initialize is called

by Emmanuel Bernard (JIRA)

Constraints can contains constraint annotations to validate params before initialize is called ---------------------------------------------------------------------------------------------- Key: HV-135 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-135 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard not high priority >From Sebastian Thomschke -------------------------------------- I just had a look through the Hibernate Validator code, what struck me was the way how you validate parameters. E.g. private void validateParameters() { if ( min < 0 ) { throw new ValidationException( "The min parameter cannot be negative." ); } if ( max < 0 ) { throw new ValidationException( "The max paramter cannot be negative." ); } if ( max < min ) { throw new ValidationException( "The length cannot be negative." ); } } I just had the idea, why don't we use the constraint annotations for the built-in constraints themselves? E.g. /** * @return size the element must be higher or equal to */ @Min(0) int min() default 0; /** * @return size the element must be lower or equal to */ @Min(0) int max() default Integer.MAX_VALUE; Then this kind of parameter validation could be done by the framework and must not be repeated in every validator implementation. What do you think? Regards, Seb -------------------------------------- Emmanuel Your idea is interesting. It could lead to infinite recursion if someone does not pay attention but could work. I think it would better be a product feature though instead of a spec feature for this rev at least. We can't have "class" level constraints though as it conflicts with the composition model. WDYT? it seems to me that the ValidationException is wrong in the example you gave. http://opensource.atlassian.com/projects/hibernate/browse/HV-134 -- 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, 1 month

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-455) Verify in the annotation processor that the groups parameter in a constraint declaration contains only interfaces

by Kevin Pollet (JIRA)

Verify in the annotation processor that the groups parameter in a constraint declaration contains only interfaces ----------------------------------------------------------------------------------------------------------------- Key: HV-455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-455 Project: Hibernate Validator Issue Type: New Feature Components: annotation-processor Reporter: Kevin Pollet Fix For: 4.x When a constraint is defined, it's possible to specify the groups it belongs. The section 3.5 of the specification says: {{quote}}Groups are represented by interfaces.{{quote}} Consequently, the annotation processor should check that only interfaces are used in the {{groups}} parameter of a constraint declaration. -- 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, 1 month

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-308) Annotation processor should consider validators registered by XML constraint mapping

by Gunnar Morling (JIRA)

Annotation processor should consider validators registered by XML constraint mapping ------------------------------------------------------------------------------------ Key: HV-308 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-308 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Reporter: Gunnar Morling Assignee: Hardy Ferentschik Fix For: 4.1.0 Background: The Bean Validation API allows the set of validators for a given constraint to be specified/overridden using XML constraint mapping files (http://docs.jboss.org/hibernate/stable/validator/reference/en/html_single...). Right now the annotation processor does not process any XML configuration files at all (neither validation.xml nor mapping files). To do: While it seems ok for now that the AP does not check constraint declarations given in XML (after all it's an *annotation* processor), I think it should evaluate the constraint definitions and the validators configured in XML. Otherwise the AP would raise false errors (as validators added in XML are ignored) or would give false positives (as validators given in @Constraint#validatedBy could be removed by "include-existing-validator='false'"). -- 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, 1 month

2
8
0 / 0

[Hibernate-JIRA] Created: (HV-450) The annotation processor should check parameter constraints

by Gunnar Morling (JIRA)

The annotation processor should check parameter constraints ----------------------------------------------------------- Key: HV-450 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-450 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Reporter: Gunnar Morling Fix For: 4.x The AP should have support for method parameter constraints. We should definitely check the parameter types as we already do for any other constraints. Additionally we might check that preconditions are not strengthened in sub-types (see HV-421), though I'd regard this as add-on. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-432) Create a Java agent to enfore method level validation (design by contract)

by Hardy Ferentschik (JIRA)

Create a Java agent to enfore method level validation (design by contract) -------------------------------------------------------------------------- Key: HV-432 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-432 Project: Hibernate Validator Issue Type: Task Components: engine Affects Versions: 4.2.0.Final Reporter: Hardy Ferentschik Fix For: 4.x Google released Contract for Java - http://code.google.com/p/cofoja/ - which is a Java implementations for Design by Contract. Googles version uses a set of annotations, an annotation processor and a runtime java agent (see their documentation). We have all the pieces for doing this as well. * We have the constraint annotations * We have an annotation processor (obviously it does something else now, but we know how to write one) * And we have Byteman I wonder whether we couldn't put these things together and create our own Contract for Java. -- 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, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-388) Support property level ScriptAssert

by jason shi (JIRA)

Support property level ScriptAssert ----------------------------------- Key: HV-388 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-388 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.1.0.Final Reporter: jason shi Assignee: Hardy Ferentschik Current hibernate validator's ScriptAssert can only defined on the Class level, not property level. In OVal,it can define the ScriptAssert at the property level,eg: {code} public class BusinessObject { @NotNull public String deliveryAddress; @NotNull public String invoiceAddress; // mailingAddress must either be the delivery address or the invoice address @Assert(expr = "_value ==_this.deliveryAddress || _value == _this.invoiceAddress", lang = "groovy") public String mailingAddress; } {code} With property level,we can get following benefit: 1. Can be used in single property validation, It's very useful in UI layer validation 2. The validation rule is close to the property definition, it's easy to manage In JSR303 spec, the ValueContext is not passed to the Contrain Validator as a parameter, so the validator can't get the "Current Bean" of the current property to be validated. The validation engine need to some special work to support this feature. OVal can do this, so it won't be a problem for hibernate validator. -- 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, 1 month

4
6
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 October 2011