October 2008 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3248) org.hibernate.cache.EhCache.toMap() throws NullPointerException

by Kenny MacLeod (JIRA)

org.hibernate.cache.EhCache.toMap() throws NullPointerException --------------------------------------------------------------- Key: HHH-3248 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3248 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Reporter: Kenny MacLeod The toMap() method of org.hibernate.cache.EhCache is not null-safe. The expression cache.get( key ).getObjectValue() Will throw a NPE, since get(key) may return a null in cases where the key exists in the cache, but the value does not, e.g. if it has expired. This should either check for the null, or the list of keys should be obtained using getKeysWithExpiredCheck(), rather than just getKeys(). -- 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

12 years, 9 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3318) Allow omitting varchar limit by default in PostgreSQL

by Luke Maurer (JIRA)

Allow omitting varchar limit by default in PostgreSQL ----------------------------------------------------- Key: HHH-3318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3318 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Hibernate 3.2.6, PostgreSQL 8.3.1 Reporter: Luke Maurer Priority: Minor Essentially, what I'd like is for a String without a given maximum length be mapped as a varchar or text rather than a varchar(255) as is now the case. The maximum doesn't do anything to improve performance or storage efficiency in PostgreSQL, so varchar(255) merely imposes an arbitrary constraint. It would be more idiomatic to use varchar where no limit is given, leaving varchar(n) for cases where the length is limited as a business rule rather than an implementation detail. (Naturally, one can always use @Lob where it's actually *important* that the column be a varchar or text. So this is definitely minor.) -- 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

12 years, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3244) Implement support NVARCHAR type

by Sergey Derugo (JIRA)

Implement support NVARCHAR type -------------------------------- Key: HHH-3244 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3244 Project: Hibernate3 Issue Type: New Feature Components: core Environment: al Reporter: Sergey Derugo JDBC 4.0 allows supports NVARCHAR type, but Hibernate doesn't handle it. Please implement support for NVarchar -- 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

12 years, 9 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2955) Unnecessary version updates in two cases.

by Sławomir Wojtasiak (JIRA)

Unnecessary version updates in two cases. ----------------------------------------- Key: HHH-2955 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2955 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: JDK 5.0 Reporter: Sławomir Wojtasiak Attachments: HibernateTest.zip I found two situations where hibernate generates unnecessary version updates. Let's illustrate it with a simple example: Session session = SessionFactory.getSession(); Transaction transaction = session.getTransaction(); transaction.begin(); Article a = new Article(); a.setName( "atricle" ); ********************************************* *** Quantity is the owner of the relation *** ********************************************* Quantity q = new Quantity(); q.setName( "quantity" ); q.setArticle( a ); a.getQuantities().add( q ); session.persist( a ); session.flush(); ***** Hibernate generates following SQLs ***** Hibernate: select nextval ('hibernate_sequence') Hibernate: select nextval ('hibernate_sequence') Hibernate: insert into Article (name, version, id) values (?, ?, ?) Hibernate: insert into Quantity (article_id, name, version, id) values (?, ?, ?, ?) ********************************************** a.getQuantities().clear(); session.flush(); *** Hibernate generates following SQLs *** Hibernate: update Article set name=?, version=? where id=? and version=? This update of version field is performed because collection of quantities is marked as dirty, but Article entity is not relation owner so nothing change in database after this clear. Should it works like this? It looks like a bug because database remain unchanged so version changing is unnecessary in my opinion. ****************************************** session.clear(); **** SECOND PROBLEM *** Now I generate true copy of persisted objects. Notice that I use HashSet instead of PersistSet which was set during persist operation. This operation is similar to merging objects prepared by SOAP, during communication with remote client for example. *********************** Article a1 = new Article(); a1.setId( a.getId() ); a1.setName( a.getName() ); a1.setVersion( a.getVersion() ); Quantity q1 = new Quantity(); q1.setArticle( a1 ); q1.setName( q.getName() ); q1.setVersion( q.getVersion() ); q1.setId( q.getId() ); a1.getQuantities().add( q1 ); a1 = (Article)session.merge( a1 ); session.flush(); ***** This operation generates following SQLs ***** Hibernate: select article0_.id as id0_1_, article0_.name as name0_1_, article0_.version as version0_1_, quantities1_.article_id as article4_3_, quantities1_.id as id3_, quantities1_.id as id1_0_, quantities1_.article_id as article4_1_0_, quantities1_.name as name1_0_, quantities1_.version as version1_0_ from Article article0_ left outer join Quantity quantities1_ on article0_.id=quantities1_.article_id where article0_.id=? Hibernate: update Article set name=?, version=? where id=? and version=? It looks like problem is located in replaceElements() method of CollectgionType class (or somewhere near it). Maybe I'm wrong but this collection was checked for changes during merge operation (See this select above.) so why it remains dirty if it contains the same data as database?. I checked this issue on other JPA implementations (OpenJPA for example) and version is not incremented after similar merge operation. ***************************************************** transaction.rollback(); -- 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

12 years, 9 months

3
2
0 / 0

[Hibernate-JIRA] Created: (EJB-318) PostUpdate callback not called after update on a collection / association (@OneToMany for example)

by Aghnar von Salza (JIRA)

PostUpdate callback not called after update on a collection / association (@OneToMany for example) -------------------------------------------------------------------------------------------------- Key: EJB-318 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-318 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Environment: Hibernate core3.2.5, entityManager 3.3.1, annotation 3.3.0, oracle 9i Reporter: Aghnar von Salza Environment is Weblogic 10 (J2EE 5), with Hibernate used as JPA provider There is no PostUpdate callback on an entity when one of its collections of other Entities (for example annoted with @OneToMany) is updated (i mean when one entity element is added or removed). JPA specification says that a postUpate must be called after the update of at least one data of an entity. I think we have to consider that a collection of other entities can be considered as data. -- 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

12 years, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3051) NPE while query.list on a Native SQL, using L2 cache

by Amit Kapoor (JIRA)

NPE while query.list on a Native SQL, using L2 cache ---------------------------------------------------- Key: HHH-3051 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3051 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5ga Database Oracle 9i Jdk - 1.4.2_13 EHCache 1.2.3 / OsCache 2.1 both Reporter: Amit Kapoor I get an NPE when i try to execute a native query. Below is the excerpt of the code that throws NPE: String sqlQuery = "select emp_id, emp_first_name from employee_mt"; SQLQuery query = session.createSQLQuery(sqlQuery); query.setCacheable(true).setCacheRegion("TEST_REGION"); query.addScalar("emp_id"); query.addScalar("emp_first_name"); List list = query.list(); query.list() throws the following NPE: java.lang.NullPointerException at org.hibernate.type.TypeFactory.disassemble(TypeFactory.java:451) at org.hibernate.cache.StandardQueryCache.put(StandardQueryCache.java:83) at org.hibernate.loader.Loader.putResultInQueryCache(Loader.java:2194) at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2138) at org.hibernate.loader.Loader.list(Loader.java:2096) at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289) at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152) at poc.hibernate.caching.QueryCaching.fireNativeSql(QueryCaching.java:112) at poc.hibernate.caching.QueryCaching.fireQuery(QueryCaching.java:38) at poc.hibernate.caching.QueryCaching.main(QueryCaching.java:27) I tried tracing through the Hibernate code code and saw that the types[] in the at the time of execution of types[i].disassemble( row[i], session, owner ) (TypeFactory.disassemble()) was holding both the types as null. However before reaching that piece of code CustomLoader.autoDiscoverTypes(resultset) had already resolved the resultTypes to appropriate values. Hope this helps. -- 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

12 years, 10 months

3
5
0 / 0

[Hibernate-JIRA] Created: (ANN-667) Foreign key name on @OneToOne

by Immo Heikkinen (JIRA)

Foreign key name on @OneToOne ----------------------------- Key: ANN-667 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-667 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Environment: Hibernate Core 3.2.5.GA , Hibernate Annotations 3.3.0.GA, Sybase ASE 15 Reporter: Immo Heikkinen Priority: Minor Attachments: Child.java, Parent.java Foreign key constraint name cannot be changed using @org.hibernate.annotations.ForeignKey on a @OneToOne with foreign key. It doesn't matter which class is annotated with @ForeignKey. Please find the test case as an attachment. Original thread on the user forum: http://forum.hibernate.org/viewtopic.php?p=2367400 -- 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

12 years, 10 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2225) NPE when eager fetching joined component with native SQL query

by Christian Bauer (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-2225 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2225 Project: Hibernate3 Type: Bug Components: query-sql Versions: 3.2.0.ga Reporter: Christian Bauer Priority: Minor Item -> many-to-one -> User -> joined component -> billingAddress This: result = session.createSQLQuery("select {i.*}, {u.*}, {ba.*} from ITEM i" + " join USERS u on i.SELLER_ID = u.USER_ID" + " left join BILLING_ADDRESS ba on u.USER_ID = ba.USER_ID" + " where u.USERNAME = :uname") .addEntity("i", Item.class) .addJoin("u", "i.seller") .addJoin("ba", "u.billingAddress") fails with: java.lang.NullPointerException at org.hibernate.loader.DefaultEntityAliases.<init>(DefaultEntityAliases.java:37) at org.hibernate.loader.custom.sql.SQLQueryReturnProcessor.generateCustomReturns(SQLQueryReturnProcessor.java:283) at org.hibernate.loader.custom.sql.SQLCustomQuery.<init>(SQLCustomQuery.java:129) at org.hibernate.engine.query.NativeSQLQueryPlan.<init>(NativeSQLQueryPlan.java:43) at org.hibernate.engine.query.QueryPlanCache.getNativeSQLQueryPlan(QueryPlanCache.java:114) at org.hibernate.impl.AbstractSessionImpl.getNativeSQLQueryPlan(AbstractSessionImpl.java:137) at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142) at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:150) -- 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

12 years, 10 months

15
24
0 / 0

[Hibernate-JIRA] Created: (EJB-385) JPA method of merge failed to insert deleted records from database

by Hari (JIRA)

JPA method of merge failed to insert deleted records from database ------------------------------------------------------------------- Key: EJB-385 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-385 Project: Hibernate Entity Manager Issue Type: Improvement Components: EntityManager Affects Versions: 3.2.0.ga Environment: 3.2.6.ga, Weblogic,JPA, Windows Reporter: Hari The following is my requirement. Suppose i have a record in database with id say, 12. i have retrieved this using a JPQL query and convert it into a transfer object ,done some processing and going to remerge this after converting it to a new entity but the id set in the new entity is same as old one ie 12. Now just before calling entityManger.merge i have deleted the record with id 12 from database. The issue is the merge opeartion is not inserting the record in database at all. But if the id set in the entity is one which is never occured in the database,the merge operation will insert the record with the id set from teh application. Is there any work around/fix for this issue. Regards Harikrishnan R -- 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

12 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3223) PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map

by Michael Newcomb (JIRA)

PersistentMap.remove() incorrect on uninitialized, non-extra-lazy map --------------------------------------------------------------------- Key: HHH-3223 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3223 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1 Reporter: Michael Newcomb Please have a look at PersistentMap.remove() and compare it to PersistentMap.put(). The put() was fixed HHH-2476 and the same fix needs to be applied to remove(). Please refer to HHH-2584 for the patch: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2584 Copied from HHH-2584: Essentially, an uninitialized PersistentMap loses the first remove() into it if defined as non-extra-lazy. The underlying cause is the code in PersistentMap#remove() which attempts to readElementByIndex(). In the case of non-extra-lazy, readElementByIndex() returns the UNKNOWN marker object which is supposed to be used to signal that the delegate map is now initialized and to remove the element directly from the map. Long story short, PersistentMap#remove() does not properly check the return value from readElementByIndex() and react accordingly. WORKAROUND: Have a copy of PersistentMap.java in your source tree with the patch applied... Thanks! -- 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

12 years, 10 months

4
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2008