December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3820) Criterion should implement equals and hashCode

by Craig (JIRA)

Criterion should implement equals and hashCode ---------------------------------------------- Key: HHH-3820 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3820 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Reporter: Craig .equals() doesn't work as expected for Criterion and its subclasses. For example: assertEquals(Restrictions.isEmpty("parents"),Restrictions.isEmpty("parents")); fails, when clearly, it should work. -- 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

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2455) "Could not close a JDBC result set" output very often

by Dirk Feufel (JIRA)

"Could not close a JDBC result set" output very often ----------------------------------------------------- Key: HHH-2455 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2455 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.2 Reporter: Dirk Feufel Priority: Minor If you call this type of code (like the DbTimestampType class does), the AbstractBatcher outputs a warning "Could not close a JDBC result set". The problem should be that closing the prepared statement internally also closes the associated result sets and the AbstractBatcher still has a reference to this result set. One possible solution might be to provide an additional method public void closeStatement(PreparedStatement ps, ResultSet rs); (as already present for closeQueryStatement) in the AbstractBatcher allowing to close both in the right order. PreparedStatement ps = null; try { ps = session.getBatcher().prepareStatement( timestampSelectString ); ResultSet rs = session.getBatcher().getResultSet( ps ); .... } finally { if ( ps != null ) { session.getBatcher().closeStatement( ps ); } } -- 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

4
17
0 / 0

[Hibernate-JIRA] Created: (HHH-6809) FooBarTest.testFindByCriteria() fails on SQL Server due to mixed expectations for Criteria.setMaxResults(0)

by John Verhaeg (JIRA)

FooBarTest.testFindByCriteria() fails on SQL Server due to mixed expectations for Criteria.setMaxResults(0) ----------------------------------------------------------------------------------------------------------- Key: HHH-6809 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6809 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR5 Environment: MS SQL Server Reporter: John Verhaeg Fix For: 4.0.0.next Looks like some dialects treat 0 as meaning no limit and others as literally zero rows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-6885) Replace ClassLoaderAwareCache with AdvancedCache.with(ClassLoader)

by Sanne Grinovero (JIRA)

Replace ClassLoaderAwareCache with AdvancedCache.with(ClassLoader) ------------------------------------------------------------------ Key: HHH-6885 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6885 Project: Hibernate Core Issue Type: Task Reporter: Sanne Grinovero Fix For: 4.0.0.next Infinispan 5.1 introduces AdvancedCache.with(ClassLoader) , which is a cleaner approach to the previously used ClassLoaderAwareCache -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-6812) HQL query for map value leads to incorrect joins in SQL

by Neukomm (JIRA)

HQL query for map value leads to incorrect joins in SQL ------------------------------------------------------- Key: HHH-6812 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6812 Project: Hibernate Core Issue Type: Bug Components: query-hql, query-sql Affects Versions: 3.6.7 Environment: Oracle Java 1.6.0_29, Hibernate 3.6.7-Final, Hsqldb 2.2.5 Reporter: Neukomm Attachments: map_query_test.zip Whenever an expression like 'where p.map['key'] = :val' is used in HQL, the join between the entity table and the map value table is not done correctly. This leads to missing results. The attached test case uses HQL like this: from MapQueryEntity p where p.name = 'B' or p.map['key'] = 'value' the corresponding sql looks like this: select mapqueryen0_.id as id0_, mapqueryen0_.name as name0_ from MapQueryEntity mapqueryen0_ cross join MapQueryEntity_map map1_ where mapqueryen0_.id=map1_.ident and map1_.mkey = 'key' and ( mapqueryen0_.name='B' or map1_.mvalue='value' ) This leads to all entities that don't have a map entry for key 'key' not to be in the result, even if they have name 'B'. SQL that would return the correct rows (at least on hsqldb) could e.g. look like this: select mapqueryen0_.id as id0_, mapqueryen0_.name as name0_ from MapQueryEntity mapqueryen0_ left outer join MapQueryEntity_map map1_ on mapqueryen0_.id=map1_.ident where mapqueryen0_.name='B' or (map1_.mkey = 'key' and map1_.mvalue='value') Looks like org.hibernate.hql.ast.tree.IndexNode (which seems to be responsible for the hql/sql translation if '[]' is used) doesn't work correctly for this case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
2
0 / 0

[Hibernate-JIRA] Created: (HV-546) LazyValidatorFactory does not allow alternative bean validation providers

by Hardy Ferentschik (JIRA)

LazyValidatorFactory does not allow alternative bean validation providers ------------------------------------------------------------------------- Key: HV-546 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-546 Project: Hibernate Validator Issue Type: Bug Components: engine Affects Versions: 4.2.0.Final Reporter: Hardy Ferentschik Fix For: 4.3.0.next The current implementation of _LazyValidatorFactory_ does not allow alternative validation providers. The idea of the class is to make sure that Hibernate Validator is the default (it should be the first returned), but it should also allow for custom providers. For this to work logic as in _Validation#DefaultValidationProviderResolver_ is needed. The same problem applies to _org.jboss.as.ee.beanvalidation.LazyValidatorFactory_ and _org.jboss.as.jpa.validator.JPALazyValidatorFactory_. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1020) Regression in 3.4: index not updated after updating a collection

by Guillaume Smet (JIRA)

Regression in 3.4: index not updated after updating a collection ---------------------------------------------------------------- Key: HSEARCH-1020 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1020 Project: Hibernate Search Issue Type: Bug Affects Versions: 4.0.0.Final, 3.4.1.Final Reporter: Guillaume Smet Hi, I know it's not exactly documented but, before 3.4, it was possible to index a collection with the @Field annotation and a FieldBridge (in our case, a FieldBridge which indexes all the ids of the linked entities). We use it a lot instead of @IndexedEmbedded because it allows us not to bloat our index when we want to index a collection containing indexed entities (@IndexedEmbedded integrates all the fields of the linked entities in the index of the main entity - which is often not needed in our case: we have autocomplete field for our search so we only need the id of the linked entities). Starting with 3.4, it doesn't work anymore: the entity is correctly indexed when created but, if we update only the collection, the index is not updated. The problem is in AbstractDocumentBuilder.isCollectionRoleExcluded(String collectionRole) which is called to check if the collection update should trigger a reindex. This method should also consider the collections having a @Field annotation, not just the collections with @IndexedEmbedded or @ContainedIn. FWIW, if somebody else has this problem, as a workaround, I use a non default boost strategy to force the reindex but it would be nice to have it fixed because it's really a useful pattern. If needed, we can provide a test case. Thanks. -- Guillaume -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

5
18
0 / 0

[Hibernate-JIRA] Created: (HV-482) Weblogic ConstrantDeclationException HVbeta2

by Tim Canavan (JIRA)

Weblogic ConstrantDeclationException HVbeta2 -------------------------------------------- Key: HV-482 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-482 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.2.0.Beta2 Environment: Weblogic 10.3 Reporter: Tim Canavan After upgrading to HV beta2 and changing all our validations to be at the interface level we get the constraint declaration exception Caused by: javax.validation.ConstraintDeclarationException: Only the root method of an overridden method in an inheritance hierarchy may be annotated with parameter constraints. The following method itself has no parameter constraints but it is not defined on a sub-type of class Under OpenEJB which our unit tests use everything works fine. Is there any code that HV could use that would allow it to understand these proxies or would an option be available to turn the check off. -- 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

4
23
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-925) Upgrade to JGroups 3

by Sanne Grinovero (JIRA)

Upgrade to JGroups 3 -------------------- Key: HSEARCH-925 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-925 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero JGroups3 is an API update, and version 3 is the one being used by newest versions of JBossAS and Infinispan so we need to upgrade. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
8
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1007) Make FullTextIndexEventListener extensible

by Sanne Grinovero (JIRA)

Make FullTextIndexEventListener extensible ------------------------------------------ Key: HSEARCH-1007 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1007 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.1 If some of the methods currently marked as private where protected people would be able to better customize it. See also https://forum.hibernate.org/viewtopic.php?f=9&t=1013755 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years

2
3
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011