[Hibernate-JIRA] Created: (HV-443) Scope of ConstraintDescriptors sometimes wrong in type hierarchies
by Gunnar Morling (JIRA)
Scope of ConstraintDescriptors sometimes wrong in type hierarchies
------------------------------------------------------------------
Key: HV-443
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-443
Project: Hibernate Validator
Issue Type: Bug
Components: engine
Affects Versions: 4.1.0.Final
Reporter: Gunnar Morling
Fix For: 4.2.0.CR1
Using the BV meta data API it is possible to retrieve meta information on the constraints of given Java types. Using the {{ConstraintFinder}} API the scope of the constraints to retrieve meta data for can be restricted.
Due to the caching of meta data in {{BeanMetaDataCache}} it can happen under certain circumstances that constraints are declared in scope {{LOCAL_ELEMENT}}, although it should be {{HIERARCHY}} instead.
The following test demonstrates the bug:
{code:java}
public class CacheTest {
@Test
public void constraintsFromSuperTypeAreInLocalScopeWhenSuperTypeIsLoadedFromCache() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
// loads BeanMetaData for A and puts it into the BeanMetaDataCache
PropertyDescriptor propertyDescriptorForSuperType = validator
.getConstraintsForClass(A.class).getConstraintsForProperty("foo");
Set<ConstraintDescriptor<?>> constraintDescriptorsFromSuperType = propertyDescriptorForSuperType
.findConstraints().lookingAt(Scope.LOCAL_ELEMENT)
.getConstraintDescriptors();
assertEquals(constraintDescriptorsFromSuperType.size(), 1);
// re-uses BeanMetaData for A from cache, keeps A's constraints in
// LOCAL_ELEMENT scope
PropertyDescriptor propertyDescriptorForSubType = validator
.getConstraintsForClass(B.class).getConstraintsForProperty("foo");
Set<ConstraintDescriptor<?>> constraintDescriptorsFromSubType = propertyDescriptorForSubType
.findConstraints().lookingAt(Scope.LOCAL_ELEMENT)
.getConstraintDescriptors();
// fails
assertEquals(constraintDescriptorsFromSubType.size(), 0, "No descriptor in LOCAL scope expected for B.foo");
}
@Test
public void constraintsFromSuperTypeAreInHierarchyScopeWhenSuperTypeIsNotLoadedFromCache() {
Validator validator = Validation.buildDefaultValidatorFactory().getValidator();
// loads BeanMetaData for A when traversing B's hierarchy, A's constraints
// are correctly in HIERARCHY scope
PropertyDescriptor propertyDescriptorForSubType = validator
.getConstraintsForClass(B.class).getConstraintsForProperty("foo");
Set<ConstraintDescriptor<?>> constraintDescriptorsFromSubType = propertyDescriptorForSubType
.findConstraints().lookingAt(Scope.LOCAL_ELEMENT)
.getConstraintDescriptors();
assertEquals(constraintDescriptorsFromSubType.size(), 0, "No descriptor in LOCAL scope expected for B.foo");
constraintDescriptorsFromSubType = propertyDescriptorForSubType
.findConstraints().lookingAt(Scope.HIERARCHY)
.getConstraintDescriptors();
assertEquals(constraintDescriptorsFromSubType.size(), 1, "One descriptor in HIERARCHY scope expected for B.foo");
}
public static class A {
@NotNull
public String getFoo() {
return null;
}
}
public static class B extends A {
}
}
{code}
The bug is caused by retrieving the meta data for {{A}} from the cache when building the meta data for its sub-type {{B}} (see {{constraintsFromSuperTypeAreInLocalScopeWhenSuperTypeIsLoadedFromCache}}). In this case the constraint from {{A}} are added to {{B}} but remain in scope {{LOCAL_ELEMENT}}.
The bug does not occur when the meta data for {{A}} is retrieved when traversing the type hierarchy while building up the meta data for {{B}} (see {{constraintsFromSuperTypeAreInHierarchyScopeWhenSuperTypeIsNotLoadedFromCache}}), though I guess the constraints would be wrongly in scope {{HIERARCHY}} if afterwards the descriptors for {{A}} itself would be retrieved.
To fix this bug the constraint scope needs to be re-determined always if the meta data is retrieved from the cache.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-6761) CollectionTable and OneToMany, collection elements duplicate.
by Evgeny Terentev (JIRA)
CollectionTable and OneToMany, collection elements duplicate.
--------------------------------------------------------------
Key: HHH-6761
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6761
Project: Hibernate Core
Issue Type: Bug
Components: core
Environment: 3.6.4.Final
Reporter: Evgeny Terentev
@Entity
@Table(name = "aaa")
public class AAA implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
private int id;
@MapKey(name = "ccc")
@OneToMany(orphanRemoval = true, cascade = {CascadeType.REMOVE}, fetch = FetchType.EAGER, mappedBy = "aaa")
private Map<CCC, BBB> bbb = new HashMap<CCC, BBB>();
@Column(name = "bonus_id")
@ElementCollection(targetClass = Long.class, fetch = FetchType.EAGER)
@CollectionTable(name = "aaa_bonus", joinColumns = @JoinColumn(name = "advert_post_id"))
public Collection<Long> bonusIds;
}
@Entity
@Table(name = "bbb")
public class BBB implements Serializable {
@Id
@GeneratedValue(strategy = GenerationType.AUTO)
public int id;
@ManyToOne(optional = false)
@JoinColumn(name = "aaa_id", nullable = false)
public AAA aaa;
@Column
public CCC ccc;
@Column
public int value;
}
public enum CCC {
AAA,
BBB,
CCC,
}
first fill tables:
AAA a = new AAA();
a.bonusIds = Arrays.asList(1L, 2L, 3L); // size = 3
em.persist(a);
BBB b = new BBB();
b.aaa = a;
b.ccc = CCC.AAA;
b.value = 1;
em.merge(b);
em.merge(b);
second get bonusIds and check size:
AAA aaa = em.find(AAA.class, 6);
if (aaa.bonusIds.size() != 3)
throw new RuntimeException();
size will be 6! but must be 3.
generate sql:
select aaa0_.id as id1_1_, bbb1_.aaa_id as aaa4_1_3_, bbb1_.id as id3_, bbb1_.ccc as formula0_3_, bbb1_.id as id0_0_, bbb1_.aaa_id as aaa4_0_0_, bbb1_.ccc as ccc0_0_, bbb1_.value as value0_0_, bonusids2_.advert_post_id as advert1_1_4_, bonusids2_.bonus_id as bonus2_4_
from aaa aaa0_
left outer join bbb bbb1_ on aaa0_.id=bbb1_.aaa_id
left outer join aaa_bonus bonusids2_ on aaa0_.id=bonusids2_.advert_post_id where aaa0_.id=?
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HHH-6763) Cross Join issue on org.hibernate.dialect.SybaseDialect
by Yassir QAISSI (JIRA)
Cross Join issue on org.hibernate.dialect.SybaseDialect
-------------------------------------------------------
Key: HHH-6763
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6763
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.6
Environment: Hibernate 3.5.6 with Sybase 12.5 and JDK 1.6
Reporter: Yassir QAISSI
This version of org.hibernate.dialect.SybaseDialect class generate sql request with a cross join when the following methode is called getCrossJoinSeparator (by native code).
Sybase 12.5 (and I think also higher) do not support the request with cross join syntax.
Here is an instance of an error on such case:
2011-10-11 18:17:37,717 [http-8080-1] [WARN ] [o.h.util.JDBCExceptionReporter] - SQL Error: 102, SQLState: 42000
2011-10-11 18:17:37,717 [http-8080-1] [ERROR] [o.h.util.JDBCExceptionReporter] - Incorrect syntax near 'cross'.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 5 months
[Hibernate-JIRA] Created: (HV-480) Constraints configured via XML and programmatic API aren't merged
by Gunnar Morling (JIRA)
Constraints configured via XML and programmatic API aren't merged
-----------------------------------------------------------------
Key: HV-480
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-480
Project: Hibernate Validator
Issue Type: Bug
Reporter: Gunnar Morling
Fix For: 4.x
The HV reference guide says
{quote}
[The programmatic] API can be used exclusively or in combination with annotations and xml. If used in combination programmatic constraints are additive to otherwise configured constraints.
{quote}
While that is right for constraints configured via annotations and programmatic API this does currently not work for constraints configured via XML and programmatic API. Currently a type's XML configuration has precedence over its programmatic configuration. The cause is that once the meta data for a type is added to the bean meta data cache in {{ValidatorFactoryImpl#initXmlConfiguration()}} programmatic meta data won't be added or merged in {{initProgrammaticConfiguration()}}.
--
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, 5 months