May 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2575) Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used

by Mike Hoeffner (JIRA)

Query results are mapped to object array incorrectly when there is column ambiguity and aliases are not used ------------------------------------------------------------------------------------------------------------ Key: HHH-2575 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2575 Project: Hibernate3 Issue Type: Bug Components: query-sql Affects Versions: 3.2.2 Environment: Hibernate 3.2.2 + MySQL 5.0.22 + MySQL Connector/J 5.0.5. Reproduced with HSQLDB 1.8.0.7. Reporter: Mike Hoeffner Priority: Minor Attachments: ResultsNotEffectedByAliasesTest.java I had a SQL (not HQL) query that basically looked like this: select a.name, a.seq, b.name, b.seq from foo a, foo b; and I noticed that the results obtained through list() -> (Object[]) get(i) -> row[0], row[1], row[2], row[3] did not correspond to what I saw when manually running the query without Hibernate involved. row[2] always had the same values as row[0] and row[3] always had the same values as row[1]. When I tried adding aliases so that it became: select a.name as a_name, a.seq as a_seq, b.name as b_name, b.seq as b_seq from foo a, foo b; then the results matched what I expected. So having aliases in the SQL modified the results that were returned even though I was looking up the value from each column by its index / position instead of by its name / alias. Attached is a test case that will reproduce this. -- 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

15 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (ANN-507) @Digits(integerDigits, fractionalDigits)

by Emmanuel Bernard (JIRA)

@Digits(integerDigits, fractionalDigits) ---------------------------------------- Key: ANN-507 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-507 Project: Hibernate Annotations Type: New Feature Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard Fix For: 3.2.2 @Digits(integerDigits=8, fractionalDigits=2) ensure that the number can be expressed with integerDigits digits and factionalDigits digits -- 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

15 years, 9 months

6
10
0 / 0

[Hibernate-JIRA] Created: (HHH-2661) Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE)

by Anders Wallgren (JIRA)

Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE) ----------------------------------------------------------------------- Key: HHH-2661 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2661 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.4.sp1 Environment: Windows Vista MySQL 5.0 Reporter: Anders Wallgren I'm doing some bulk importing and want to disable the L2 cache, so I call Session.setCacheMode(CacheMode.IGNORE) before doing any work. However, the entities I'm creating still end up in the cache. It seems that org.hibernate.action.CollectionAction isn't doing the correct check to determine when to cache -- it only check for the existence of a configured cache, but doesn't check whether caching is enabled in the session. For example, from CollectionAction.beforeExecutions: public final void beforeExecutions() throws CacheException { // we need to obtain the lock before any actions are // executed, since this may be an inverse="true" // bidirectional association and it is one of the // earlier entity actions which actually updates // the database (this action is resposible for // second-level cache invalidation only) if ( persister.hasCache() ) { final CacheKey ck = new CacheKey( key, persister.getKeyType(), persister.getRole(), session.getEntityMode(), session.getFactory() ); lock = persister.getCache().lock(ck, null); } } Shouldn't "if ( persister.hasCache() )" be persistence.hasCache && getSession.getCacheMode.isPutEnabled(), or something along those lines? -- 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

15 years, 9 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3278) JPA query does not work on Derby when more than one entity has a column named DATE

by Felipe Leme (JIRA)

JPA query does not work on Derby when more than one entity has a column named DATE ---------------------------------------------------------------------------------- Key: HHH-3278 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3278 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, Hibernate Annotations 3.3.0, Hibernate Entity Manager 3.3.1, Derby 10.4.1.3 Reporter: Felipe Leme I have a relationship that is more like this (sorry, didn't have time to provide a simpler scenario): - MP has a field/column called date - MPHistory also have the same field - there is a 1-N relationship between MP -> MPHistory - the relationship has a @OrderBy("date") clause When Hibernate starts using H2, everything works fine. But if I use Derby, I get the following exception: Caused by: java.sql.SQLException: Column name 'DATE' appears more than once in the result of the query expression. The bad SQL is the following: Hibernate: select distinct agententit0_.id as id1_0_, mps1_.id as id0_1_, history2_.id as id3_2_, agententit0_.connected as connected1_0_, agententit0_.jmx_name as jmx4_1_0_, agententit0_.status as status1_0_, agententit0_.host_id as host10_1_0_, agententit0_.host as host1_0_, agententit0_.local as local1_0_, agententit0_.port as port1_0_, agententit0_.type as type1_0_, mps1_.date as date0_1_, mps1_.name as name0_1_, mps1_.value as value0_1_, mps1_.frequency_type as frequency5_0_1_, mps1_.is_full_mode as is6_0_1_, mps1_.is_historical as is7_0_1_, mps1_.is_normal_mode as is8_0_1_, mps1_.tolerance as tolerance0_1_, mps1_.is_summary_mode as is10_0_1_, mps1_.value_class as value11_0_1_, mps1_.info_id as info12_0_1_, mps1_.obj_id as obj13_0__, mps1_.id as id0__, history2_.date as date3_2_, history2_.value as value3_2_, history2_.value_class as value4_3_2_, history2_.mp_id as mp5_1__, history2_.id as id1__ from ggs_objects agententit0_ left outer join mps mps1_ on agententit0_.id=mps1_.obj_id left outer join mps_history history2_ on mps1_.id=history2_.mp_id where agententit0_.type in (108, 8) order by date asc More specifically, the final 'order by date asc' should be 'order by history2_.date asc'. Doing some debugging, I found the problem at org.hibernate.sql.Template, method isFunctionOrKeyword (line 304), which returns: "(".equals(nextToken) || KEYWORDS.contains(lcToken) || functionRegistry.hasFunction(lcToken) || dialect.getKeywords().contains(lcToken) || FUNCTION_KEYWORDS.contains(lcToken); The 3rd check ( dialect.getKeywords().contains(lcToken) ) returns true for Derby, then the whole method returns true, which in turns does not prepend the "$PlaceHolder$ (history2_, in this case), in the query: else if ( isIdentifier(token, dialect) && !isFunctionOrKeyword(lcToken, nextToken, dialect, functionRegistry) // <<<<< THIS IS THE ISSUE >>>> ) { result.append(TEMPLATE) .append('.') .append( dialect.quote(token) ); } For now, I just removed the @OrderBy from my query (it's not really important in my case), but it looks like the Template method logic is wrong in this case. PS: I initially open the same ticket at JBoss' site (http://jira.jboss.org/jira/browse/HIBERNATE-95) - my mistake, I guess I should have opened it here instead... -- 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

15 years, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2668) Caching Fails with Composite-Ids Containing Nested, Complex Entities

by Juan Osuna (JIRA)

Caching Fails with Composite-Ids Containing Nested, Complex Entities -------------------------------------------------------------------- Key: HHH-2668 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2668 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.4.sp1 Environment: Problem is independent of environment or platform and most likely exists in prior versions. Reporter: Juan Osuna Attachments: hibernate-caching-fix.zip Description of Failing Test Case Scenario Preconditions: An entity class is mapped that uses a composite-id that contains a nested entity class. Only the composite-id class implements equals/hashcode, not the nested entity class. Steps to Reproduce: 1. open session and fetch object using composite-id 2. open new session and fetch same object again using different instance of composite-id but with same identity Invalid Postconditions: On second retrieve, Hibernate fails to get the object from the cache and unnecessarily reloads the object. CachKeys containing different instances of the composite-id always fail to be equal even though they have the same persistent identity. Attachment Contents Code fix is attached as well as a Junit test case that reproduces the problem and validates the fix. The full Hibernate suite was also executed with no impact. Attachment contains: New Test Method: org.hibernate.test.cache.BaseCacheProviderTestCase.testQueryCacheComplexItem New Test Entity Items: org\hibernate\test\cache\ComplexItem.hbm.xml org.hibernate.test.cache.ComplexItem org.hibernate.test.cache.ComplexItemPK Code Fix: org.hibernate.cache.CacheKey (see FIX comments) Problem and Fix Details Hibernate generally strives to use persistent identifiers for managing object identity rather than the equals/hashcode methods implemented by entity classes. While it is good practice to implement equals/hashcode, Hibernate does not generally force users to do this. When wrapping a composite-id object, the current implementation of CacheKey fails to recurse through nested complex entities to query for equality based on persistent identity. Instead, when the recursion algorithm hits a complex entity, it invokes equals directly on that entity rather than further recursing through the identifier object. Notably, the recursion logic for equals is not symmetrical with the recursion logic for hashcode, which does recurse through identifier objects. So, while CacheKey never invokes hashcode on nested complex entities, it does invoke equals on these entities. A simple fix to this inconsistency is to store the factory parameter passed to CacheKey and later pass that parameter to the overloaded method: Type.isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory). This fix restores symmetry to equals and hashcode behavior. By calling this overloaded method, the thread of execution will enter EntityType. isEqual(Object x, Object y, EntityMode entityMode, SessionFactoryImplementor factory), which correctly recurses through complex identifiers. Design Principles Hibernate should strive to behave predictably even in scenarios where users do not follow best practices. Hibernate should strive to be as forgiving as possible as long there is no negative consequence caused by such forgiveness. Hibernate should behave as consistently as possible. If Hibernate does not generally rely user-implemented equals/hashcode, it is best to avoid exceptions to this rule wherever possible. Possible Future Enhancement Mapping composite-ids that contain complex entities can cause deep object graphs to be cached as part of CacheKey. This is unsettling because of it's potential to consume memory unnecessarily and unpredictably. Currently, CacheKey caches the hashcode by recursing through a complex graph of identifier objects. Perhaps, it would also be possible for CacheKey to cache an object graph of identifier objects whose leaves hold primitive values. This would further add symmetry between hashcode and equals and lighten the load for caching composite-ids that hold entity classes. Robustly supporting composite-ids that hold complex identifiers seems like a worthwhile design goal. -- 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

15 years, 9 months

6
8
0 / 0

[Hibernate-JIRA] Created: (HHH-2047) make Query and Criteria extend java.lang.Iterable

by Amir Pashazadeh (JIRA)

make Query and Criteria extend java.lang.Iterable ------------------------------------------------- Key: HHH-2047 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2047 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.cr2 Reporter: Amir Pashazadeh Priority: Trivial Objects which implement java.lang.Iterable can be iterated using extended for loop. -- 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

15 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (ANN-407) <synchronize table="table_name"/> is missed using annotations

by Amir Pashazadeh (JIRA)

<synchronize table="table_name"/> is missed using annotations -------------------------------------------------------------- Key: ANN-407 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-407 Project: Hibernate Annotations Type: Patch Components: binder Versions: 3.2.0.cr1 Reporter: Amir Pashazadeh in old .hbm.xml notation there was a possibility to set a synchronize for caches on particular tables, and I could not find such thing using annotations, is it possible to set "synchronize" tables using annotations? and if not will it be added to 3.2? -- 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

15 years, 10 months

3
3
0 / 0

[Hibernate-JIRA] Created: (ANN-660) HHH-2545 Alive

by Eugene Batogov (JIRA)

HHH-2545 Alive -------------- Key: ANN-660 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-660 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.0.ga Environment: Gentoo Linux x86 JDK: 1.6. SUN and BEA JBoss-4.2.1.GA Hibernate: 3.2.5 Annotation: 3.3.0.GA EntityManager: 3.3.1 Reporter: Eugene Batogov Priority: Critical I have a same problem how in HHH-2545 bug ! I update Hibernate to 3.2.5, hibernate-annotation to 3.3.0.GA hibernate-entitymanager to 3.3.1.GA. But this bug alive! I use ehcache-1.3.0. jBoss-4.2.1.GA. My query, which get from cache with null elements in collections: Long customerAccount = customerIdentity.getCustomerAccount().getId(); try{ String sql = "select npvr.npvrChannels from NpvrServiceSpec npvr"+ " where npvr.id in ("+ " select ss.id from Customer cust join cust.accounts acc join cust.subscriptions sub"+ " join sub.serviceSpecifications ss"+ " where acc.id =:customerAccount and"+ " ss in (from NpvrServiceSpec))"; Query query = emanager.createQuery(sql); query.setParameter("customerAccount", customerAccount); query.setHint("org.hibernate.cacheRegion", "query.findQueryNpvrChannelsBySubsription"); query.setHint("org.hibernate.cacheable", true); result = query.getResultList(); Help me, please ! Thanks in advance. -- 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

15 years, 10 months

5
12
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-53) Add support for projection (ie read the data from the index only)

by Emmanuel Bernard (JIRA)

Add support for projection (ie read the data from the index only) ----------------------------------------------------------------- Key: HSEARCH-53 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-53 Project: Hibernate Search Issue Type: New Feature Components: query Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.0.0.beta2 -- 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

15 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2928) optimizers for enhanced id generators should be synchronized against multi-threaded access

by Steve Ebersole (JIRA)

optimizers for enhanced id generators should be synchronized against multi-threaded access ------------------------------------------------------------------------------------------ Key: HHH-2928 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2928 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6 Currently the optimizers do not serialize access to their internal state when applying their optimizations. This only affects the pooled and hilo optimizers. -- 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

15 years, 10 months

4
12
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 2008