October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3494) HQLQueryPlan gives back zero result for "getSingleResult()" although one result is available

by Christian Hofschroer (JIRA)

HQLQueryPlan gives back zero result for "getSingleResult()" although one result is available -------------------------------------------------------------------------------------------- Key: HHH-3494 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3494 Project: Hibernate Core Issue Type: Bug Components: query-hql Affects Versions: 3.3.1 Environment: 3.3.1.GA, hsqldb 1.8.0.7 Reporter: Christian Hofschroer Attachments: patch.txt I have run the following code snippets both and only the second one works, because there is a bug in HQLQueryPlan. // This does not work correctly (query is javax.persistence.Query) ExampleObject e = (ExampleObject) query.getSingleResult(); // Replacement with this code works List l=query.getResultList() ; assertEquals(1,l.size()) ; ExampleObject e=(ExampleObject)l.get(0) ; This problem occurs only in seldom cases when 1. Hibernate executes several sql queries and merges the result and 2. There is a limit of results (the limit is "2" in version 3.3.1.GA, because only one result is expected anyway) Attached is a patch for the class HQLQueryPlan. The line if ( distinction.add( result ) ) { has to be replaced with if ( ! distinction.add( result ) ) { In case the object was found it returns "true". With the current implementation the object is not added to "combinedResults" although it should be added. It was not possible to reproduce the problem with the setup from "testsuite". If necessary I can provide a JUnit testcase. -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-360) DefaultTraversableResolver.isReachable() should be enhanced to return true for validations with group other than Default

by Georges-Etienne Legendre (JIRA)

DefaultTraversableResolver.isReachable() should be enhanced to return true for validations with group other than Default ------------------------------------------------------------------------------------------------------------------------ Key: HV-360 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-360 Project: Hibernate Validator Issue Type: Improvement Affects Versions: 4.1.0.Final Reporter: Georges-Etienne Legendre Assignee: Hardy Ferentschik We use Bean Validator to validate transition between domain object states. We use groups to allow different validations for each state. When we want to change the state of an object, we get the object from the database (using JPA). However, because we use LAZY loading, only the loaded beans get validated. This causes problems because nothing is in fact validated (other than the first bean of course). I know the JSR tells that the default TraversableResolver should verify if JPA is in the classpath. However, this doesn't make sense when groups are used for the purpose described above. There are 2 workarounds: * Disable LAZY loading! * Implement a TraversableResolver that returns true for isReachable() However, I'm wondering if the DefaultTraversableResolver.isReachable() can be enhanced to return true for validations with group other than Default. -- 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, 7 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3571) Change the default revision entity configuration

by Adam Warski (JIRA)

Change the default revision entity configuration ------------------------------------------------ Key: HHH-3571 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3571 Project: Hibernate Core Issue Type: Task Components: envers Reporter: Adam Warski Assignee: Adam Warski Fix For: 3.4 The current revision table and field names are not accepted by databases such as Oracle. Hence: - change the revision entity name from _revision_entity to something acceptable by all databases (REVISION_ENTITY?) - change the revision field name from _revision (to revision?) Also, change the default id generation strategy from native to org.hibernate.id.enhanced.SequenceStyleGenerator Document those changes in the manual with a migration note! -- 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, 7 months

3
12
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-531) Use Lucene fieldcache

by Sanne Grinovero (JIRA)

Use Lucene fieldcache --------------------- Key: HSEARCH-531 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-531 Project: Hibernate Search Issue Type: Improvement Components: query Reporter: Sanne Grinovero Fix For: 3.4.0 The Lucene per-segment FieldCache should be used for strings we fetch from the index (Stored), by default as we do with classname and PK. It might be useful for people to be able to add more fields to this cache in case of projections usage. (It's purpose is to speed up this reading of stored info - being per segment it's not invalidated per new IndexReader but per changed segments). Likely need a switch to turn it off, as it could consume much memory. -- 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, 7 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HV-371) Support method-level constraints in meta-data API

by Gunnar Morling (JIRA)

Support method-level constraints in meta-data API ------------------------------------------------- Key: HV-371 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-371 Project: Hibernate Validator Issue Type: Sub-task Components: engine Reporter: Gunnar Morling Assignee: Gunnar Morling Fix For: 4.2.0 -- 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, 7 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3121) Using fetch="subselect" and second level cache causes NullPointerException

by Adam Brod (JIRA)

Using fetch="subselect" and second level cache causes NullPointerException -------------------------------------------------------------------------- Key: HHH-3121 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3121 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Environment: Oracle 10g Reporter: Adam Brod I've been tuning some of our mappings to use fetch="subselect" to reduce the number of DB queries. However, I have run into two cases where I get the exception below. In both cases, I was loading a list of Videos, which are mapped to a list of other objects. (In this example, Media is the superclass of Video.) I apologize that I can't upload a full working example, but I will include the relevant mapping info. <class name="Media" table="media" lazy="false" discriminator-value="0"> <cache usage="nonstrict-read-write"/> <id name="id" column="id" type="long"> <generator class="seqhilo"><param name="sequence">hibernate_hi_sequence</param><param name="max_lo">500</param></generator> </id> ... <list name="tags" lazy="true" table="media_tags" cascade="save-update" fetch="subselect"> <cache usage="nonstrict-read-write"/> <key column="media_id"/> <list-index column="idx"/> <many-to-many column="tag_id" class="com.brightcove.catalog.Tag"/> </list> ... <subclass name="Video" lazy="false" discriminator-value="1"> ... </subclass> </class> <class name="Tag" table="tag"> ... </class> The HQL being executed is just a simple "from Video v where v.publisher_id = :pubId". The line of code where the exception is generated in Video.getDTO() is accessing the Tags list: for (Tag tag : getTags()) { tags.add(tag.getDTO()); } I've debugged into the Hibernate source to see where the NPE comes from (CollectionLoadContext line 298). if ( persister.isVersioned() ) { versionComparator = persister.getOwnerEntityPersister().getVersionType().getComparator(); final Object collectionOwner = getLoadContext().getPersistenceContext().getCollectionOwner( lce.getKey(), persister ); version = getLoadContext().getPersistenceContext().getEntry( collectionOwner ).getVersion(); //NPE! } It seems that "collectionOwner" is null, so calling getEntry(collectionOwner) returns null. Calling getVersion() on a null entry is what throws the NPE. java.lang.NullPointerException at org.hibernate.engine.loading.CollectionLoadContext.addCollectionToCache(CollectionLoadContext.java:298) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollection(CollectionLoadContext.java:256) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:222) at org.hibernate.engine.loading.CollectionLoadContext.endLoadingCollections(CollectionLoadContext.java:195) at org.hibernate.loader.Loader.endCollectionLoad(Loader.java:877) at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:865) at org.hibernate.loader.Loader.doQuery(Loader.java:729) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) at org.hibernate.loader.Loader.loadCollectionSubselect(Loader.java:2066) at org.hibernate.loader.collection.SubselectCollectionLoader.initialize(SubselectCollectionLoader.java:58) at org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565) at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:60) at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1716) at org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) at org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) at org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) at org.hibernate.collection.PersistentList.size(PersistentList.java:91) at com.brightcove.catalog.EconomicEntity.populateDTO(EconomicEntity.java:460) at com.brightcove.catalog.Media.populateDTO(Media.java:192) at com.brightcove.catalog.Video.populateDTO(Video.java:854) at com.brightcove.catalog.Video.getDTO(Video.java:783) at com.brightcove.catalog.Video.getDTO(Video.java:756) -- 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, 7 months

7
16
0 / 0

[Hibernate-JIRA] Created: (HHH-5651) Wire in new services in org.hibernate.service

by Gail Badner (JIRA)

Wire in new services in org.hibernate.service --------------------------------------------- Key: HHH-5651 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5651 Project: Hibernate Core Issue Type: Task Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 4.0.0.Alpha1 Wire in new services in org.hibernate.service. -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5619) Support legacy TransactionFactory names

by Steve Ebersole (JIRA)

Support legacy TransactionFactory names --------------------------------------- Key: HHH-5619 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5619 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Gail Badner Fix For: 4.0.0.Alpha1 In the short term interest of migration, have the Transactionfactory service initiator recognize the legacy class names in addition to the new names -- 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, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5687) Extract SQL keywords from DatabaseMetaData

by Steve Ebersole (JIRA)

Extract SQL keywords from DatabaseMetaData ------------------------------------------ Key: HHH-5687 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5687 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Fix For: 4.0.0.Alpha1 {{java.sql.DatabaseMetaData.html#getSQLKeywords}} is defined to return the (comma separated list of) keywords for the given database above-and-beyond the set of standard (SQL 2003) keywords. We should leverage this information while we build the JbdcServices to build out a fuller picture of database keywords to allow Dialect developers a choice between defining keywords themselves versus utilizing the extracted information. This would become part of the {{org.hibernate.engine.jdbc.spi.ExtractedDatabaseMetaData}}. The list of SQL 2003 keywords can be found at http://savage.net.au/SQL/sql-2003-2.bnf.html#xref-keywords -- 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, 7 months

1
2
0 / 0

[Hibernate-JIRA] Created: (ANN-687) orm.xml - cleanup respecting column names

by darren hartford (JIRA)

orm.xml - cleanup respecting column names ----------------------------------------- Key: ANN-687 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-687 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Environment: mysql 5, MS SQL 2000, Win2000, hibernate 3.2.4 Reporter: darren hartford couple of issues with orm.xml mapping file that is not fully implemented and needs cleanup. many-to-many table mapping not respecting column names. http://forum.hibernate.org/viewtopic.php?t=982330 id-class not respecting column names (end of an old issue, repeated with different scenario). http://opensource.atlassian.com/projects/hibernate/browse/ANN-361 <id-class class="MyTestId"/> <attributes> <id name="compoundOne"> <column name="COMPOUND_ONE"/> </id> <id name="compoundTwo"> <column name="COMPOUND_TWO"/> </id> ... WARNING: Preparing the statement failed: Invalid column name 'compoundOne'. WARNING: Preparing the statement failed: Invalid column name 'compoundTwo'. ========== Use case and urgency of issue related to external technology integration. -DTO should not require hibernate-annotations to be used in client-code, but is required when using annotations. orm.xml approach removes this limitation. -GWT 1.4 does not work with java 1.5/annotated DTO. Although everyone keeps pushing it off saying 'GWT 1.5 is on the way', it is not and solutions that should have been working to work around that limitation need to be working correctly. -- 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, 7 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010