May 2011 - hibernate-issues - Jboss List Archives

[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

13 years, 3 months

2
8
0 / 0

[Hibernate-JIRA] Created: (BVAL-24) What should be done when multiple META-INF/validation.xml are found?

by Emmanuel Bernard (JIRA)

What should be done when multiple META-INF/validation.xml are found? -------------------------------------------------------------------- Key: BVAL-24 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-24 Project: Bean Validation Issue Type: Task Components: spec-general Reporter: Emmanuel Bernard -- 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

13 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6188) java.util.UUID cannot be used for Ids

by Thomas Oellrich (JIRA)

java.util.UUID cannot be used for Ids ------------------------------------- Key: HHH-6188 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6188 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.3 Environment: Hibernate 3.6.3Final, Oracle 9i Reporter: Thomas Oellrich Attachments: Foo.java, foo.sql, fullstacktrace.txt Hibernate successfully maps java.util.UUID to a database field defined as raw(16) in Oracle. However, as soon as I add the @Id annotation from the JPA-API, I get the following error: Caused by: org.hibernate.MappingException: No Dialect mapping for JDBC type: -2 at org.hibernate.dialect.TypeNames.get(TypeNames.java:77) at org.hibernate.dialect.TypeNames.get(TypeNames.java:100) at org.hibernate.dialect.Dialect.getTypeName(Dialect.java:296) at org.hibernate.mapping.Column.getSqlType(Column.java:208) at org.hibernate.mapping.Table.sqlTemporaryTableCreateString(Table.java:371) at org.hibernate.mapping.PersistentClass.prepareTemporaryTables(PersistentClass.java:774) at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:272) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1845) at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:906) I'm using org.hibernate.dialect.Oracle9iDialect. -- 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

13 years, 3 months

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3434) hql insert doesn't work when inserting into a table with composite-id

by Ning Zhang (JIRA)

hql insert doesn't work when inserting into a table with composite-id ---------------------------------------------------------------------- Key: HHH-3434 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3434 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: 3.2.6GA, any database Reporter: Ning Zhang I have a table serving as an association table, so the Id of the table is just the ids from the linked tables. The mapping file looks like: <class name="UserPt" table="user_pt" > <composite-id> <key-property name="userId" type="java.lang.Long" column="user_id"/> <key-property name="ptId" type="java.lang.Long" column="pt_id"/> </composite-id> </class> And I need to run some HQL to insert the association into the table like: INSERT INTO UserPt(userId, ptId) SELECT user.id, pt.id FROM........... When I run this HQL, it gives an error saying: "can only generate ids as part of bulk insert with either sequence or post-insert style generators". I logged the bug in http://opensource.atlassian.com/projects/hibernate/browse/HHH-3400, but it is closed because I asked for a workaround. So this time I am not asking for anthing, just report 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

13 years, 3 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-4596) Bulk insertion with assigned identifiers

by Zoran Regvart (JIRA)

Bulk insertion with assigned identifiers ---------------------------------------- Key: HHH-4596 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4596 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5.0-Beta-2 Environment: latest hibernate, but tracing this since batch processing inception Reporter: Zoran Regvart Attachments: assigned-bulk-insert.patch supportsIdGenWithBulkInsertion method of HqlSqlWalker explicitly checks if the id generator is either SequenceGenerator or PostInsertIdentifierGenerator, I think this could be extended to include Assigned id generator, attached is the patch for that -- 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

13 years, 3 months

5
18
0 / 0

[Hibernate-JIRA] Created: (HHH-6121) Hibernate statistics should log at DEBUG level instead of INFO

by Philippe Laflamme (JIRA)

Hibernate statistics should log at DEBUG level instead of INFO -------------------------------------------------------------- Key: HHH-6121 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6121 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.6 Reporter: Philippe Laflamme With HHH-3659 came lots of output at INFO level during bulk operations: {noformat} 2011-04-13 14:16:21,538 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 2011-04-13 14:16:21,538 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 2011-04-13 14:16:21,577 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 2011-04-13 14:16:21,577 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 2011-04-13 14:16:21,626 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 2011-04-13 14:16:21,626 - INFO - hibernate.stat.Statistics - HQL: null, time: 0ms, rows: 0 {noformat} Hibernate used to be completely silent (except at startup) when set at the INFO level. Now, it is very verbose. If someone needs query timings they are probably debugging something. This output should probably set at DEBUG level instead of INFO. -- 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

13 years, 3 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3440) 3.3.0 GA with MySQL 5.0 throws table validation exception

by Carlo Luib-Finetti (JIRA)

3.3.0 GA with MySQL 5.0 throws table validation exception --------------------------------------------------------- Key: HHH-3440 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3440 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.GA Environment: Hibernate 3.3.0 GA MySQL 5.0 JBoss 4.2.2 Reporter: Carlo Luib-Finetti Hibernate immediately throws an exception at application startup, when it does the schema validation. org.hibernate.HibernateException: Wrong column type in dpjw.assessment for column NOTES. Found: text, expected: longtext Comparing the sources of 3.2.0 with 3.3.0 I can see that someone set two java statements into comment. The 3.2 version of MySQLDialect.java looks like this: protected void registerVarcharTypes() { registerColumnType( Types.VARCHAR, "longtext" ); registerColumnType( Types.VARCHAR, 16777215, "mediumtext" ); registerColumnType( Types.VARCHAR, 65535, "text" ); registerColumnType( Types.VARCHAR, 255, "varchar($l)" ); } while the new 3.3.0 version is this: protected void registerVarcharTypes() { registerColumnType( Types.VARCHAR, "longtext" ); // registerColumnType( Types.VARCHAR, 16777215, "mediumtext" ); // registerColumnType( Types.VARCHAR, 65535, "text" ); registerColumnType( Types.VARCHAR, 255, "varchar($l)" ); } If I uncomment these (and others in the same Java file!), the validation process is ok. Is there any reason why these statements (and others!) were commented out??? -- 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

13 years, 3 months

6
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3530) The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA

by Geoffrey De Smet (JIRA)

The code in the 3.3.1.GA subversion tag is not the code that's been released on the maven repository.jboss.org as 3.3.1.GA -------------------------------------------------------------------------------------------------------------------------- Key: HHH-3530 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3530 Project: Hibernate Core Issue Type: Bug Components: build Affects Versions: 3.3.1 Reporter: Geoffrey De Smet Here's the proof: http://fisheye.jboss.org/browse/Hibernate/core/tags/hibernate-3.3.1.GA/co... contains the lines (44-45): registerColumnType( Types.CLOB, "longtext" ); registerColumnType( Types.CLOB, 16777215, "mediumtext" ); registerColumnType( Types.CLOB, 65535, "text" ); But the sources jar downloaded from http://repository.jboss.org/maven2/org/hibernate/hibernate-core/3.3.1.GA/... file org\hibernate\dialect\MySQLDialect.java so on my pc C:\Documents and Settings\gds\.m2\repository\org\hibernate\hibernate-core\3.3.1.GA\hibernate-core-3.3.1.GA-sources.jar!\org\hibernate\dialect\MySQLDialect.java has these lines (66-68) instead: registerColumnType( Types.CLOB, "longtext" ); // registerColumnType( Types.CLOB, 16777215, "mediumtext" ); // registerColumnType( Types.CLOB, 65535, "text" ); It's not just some copyright stuff that been added (giving it different line numbers), some lines are clearly commented out. Maybe untagged changes happened in other files too? -- 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

13 years, 3 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-3930) one-to-one causes redundant select query

by Martijn Dashorst (JIRA)

one-to-one causes redundant select query ---------------------------------------- Key: HHH-3930 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3930 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Martijn Dashorst @Entity public class Address { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @OneToOne(mappedBy = "address") private Customer customer; } @Entity public class Customer { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; @OneToOne(fetch = FetchType.EAGER, cascade = CascadeType.ALL) private Address address = new Address(); public Long getId() { return id; } public Address getAddress() { return address; } } This mapping causes 2 instead of the expected 1 query to retrieve a Customer and its Address from the db: select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.id=? select * from Customer customer0_ left outer join Address address1_ on customer0_.address_id=address1_.id where customer0_.address_id=? Changing the mapping to a LAZY fetch type: @OneToOne(fetch = FetchType.LAZY, cascade = CascadeType.ALL) private Address address = new Address(); Causes 3 select queries instead of the expected 2 queries to retrieve a Customer (and its Address) from the db: select * from Customer customer0_ where customer0_.id=? select * from Address address0_ left outer join Customer customer1_ on address0_.id=customer1_.address_id where address0_.id=? select * from Customer customer0_ where customer0_.address_id=? The third select is superfluous because the relationship is already completely known: you already have the customer, so why not just set it on the address entity? Making the address field in Customer a @ManyToOne doesn't make a difference. Making the customer field in Address a @OneToMany does remove the extra select, but forces our model to change the relationship from Customer to List<Customer> where we *know* there'll be only 1 element. Apparently Hibernate can figure out the reverse relationship with a @ManyToOne - @OneToMany without the need for additional queries, can't this be extended to @OneToOne bidirectional relationships as well? -- 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

13 years, 3 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-574) Allow @DocumentId independed of @Id on different member

by Hardy Ferentschik (JIRA)

Allow @DocumentId independed of @Id on different member ------------------------------------------------------- Key: HSEARCH-574 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-574 Project: Hibernate Search Issue Type: Bug Components: engine Affects Versions: 3.3.0.Alpha1 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.3.0 See forum thread - https://forum.hibernate.org/viewtopic.php?f=9&t=1006457 -- 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

13 years, 3 months

3
8
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues May 2011