January 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (METAGEN-52) Remove dependency to JPA jar/classes

by Hardy Ferentschik (JIRA)

Remove dependency to JPA jar/classes ------------------------------------ Key: METAGEN-52 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-52 Project: Hibernate Metamodel Generator Issue Type: Improvement Components: processor Affects Versions: 1.1.1.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 1.x It should be possible to remove all dependencies to JPA classes in the annotation processor. The advantage would be that when configuring the processor one does not have to specify a processor classpath. On the other hand, when using the processor you will always need a JPA jar anyways since otherwise your code won't compile. So the only benefit is a slightly "easier" configuration of the processor. See also https://issues.jboss.org/browse/WELD-835 -- 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, 11 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6979) QueryPlanCache is not used in an optimal way

by Jan Stolze (JIRA)

QueryPlanCache is not used in an optimal way -------------------------------------------- Key: HHH-6979 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6979 Project: Hibernate ORM Issue Type: Bug Affects Versions: 3.6.1 Reporter: Jan Stolze Priority: Critical Attachments: FlushAndTransactionTest.java The criteria query uses the HQLQueryPlan in order to speed things up unfortunately it uses poor keys to do so. That is it resolves various parameters in the query which is used as cache key. An example: the query select id, name from book where id=? should be used as key for the cache. But instead of this it uses: select id, name from book where id=1 So the next time this query is executed with id=2 it will not be found in the QueryPlanCache which results in the creation of a new HQLQueryPlan this is not very efficient I would say. This problem can be seen when executing the FlushAndTransactionTest#testNoCache method and adding a breakpoint on SessionImpl#list(String query, QueryParameters queryParameters) method. The supplied query is not what I expect select id, name from book where id:= param1 but select id, name from book where id=1, or 2 etc. This query argument is used for retrieving the HQLQueryPlan from the QueryPlanCache. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6978) JPA criteria query in is very slow when compared to hibernate criteria

by Jan Stolze (JIRA)

JPA criteria query in is very slow when compared to hibernate criteria ---------------------------------------------------------------------- Key: HHH-6978 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6978 Project: Hibernate ORM Issue Type: Bug Components: query-criteria Affects Versions: 3.6.1 Reporter: Jan Stolze Attachments: FlushAndTransactionTest.java The criteria query using in clause is very slow when compared to Hibernate criteria queries. See attached test code which is an extension of the test code which is delivered with the hibernate-entitymanager-3.4.0.GA package FlushAndTransactionTest#testPoorSelect Using a simple select on basis of name and id thus: select * from book where id=1 and name in ('1','2','3',..) when the in clause is large than it perform really bad when using JPA criteria queries. On my local machine when in clause contains 1500 elements: Using Hibernate criteria it took +/-0 ms when using JPA criteria it took +/-670 ms (!!!) a stunning amount of time. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6976) Duplicated actions in session actionQueue

by sergio rolanski (JIRA)

Duplicated actions in session actionQueue ----------------------------------------- Key: HHH-6976 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6976 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 3.6.9 Environment: tomcat 7, hibernate 3.6.9, netbeans 7.0.1 Reporter: sergio rolanski Attachments: hibernate3-6-9.png While trying to solve some a problem in our application and I managed to find a "Cannot insert duplicate row" error. Investigating further I find something that seems like a problem in Hibernate's. (not a bug, a problem...) ActionQueue class is using ArrayList to hold the actions. Attached is an image of what happened. Using ArrayList allow for duplicate entries in the action queue. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (METAGEN-62) SortedSet attributes are not included in metamodel

by Patrice Blanchardie (JIRA)

SortedSet attributes are not included in metamodel -------------------------------------------------- Key: METAGEN-62 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-62 Project: Hibernate Metamodel Generator Issue Type: Improvement Components: processor Affects Versions: 1.1.1.Final Reporter: Patrice Blanchardie Assignee: Hardy Ferentschik SortedSet collections (with @Sort etc.) are not included in generated metamodel. Is it the wanted behavior, even if collections are annotated with @OneToMany/@ManyToMany? It produces the following error: "Unable to locate static metamodel field ..." -- 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, 11 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-6512) Setup Oracle integration tests

by Karel Maesen (JIRA)

Setup Oracle integration tests ------------------------------ Key: HHH-6512 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6512 Project: Hibernate Core Issue Type: Sub-task Reporter: Karel Maesen -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3383) QueryKey is storing references to entities instead of identifiers

by Manuel Dominguez Sarmiento (JIRA)

QueryKey is storing references to entities instead of identifiers ----------------------------------------------------------------- Key: HHH-3383 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3383 Project: Hibernate3 Issue Type: Improvement Components: caching (L2) Affects Versions: 3.3.0.CR1 Environment: ehcache 1.5.0b2 Reporter: Manuel Dominguez Sarmiento Context: query caching Hibernate is storing full entity references when building QueryKeys and the query has restrictions which reference entities. This happens either with Criteria or HQL queries. Although this is not incorrect, when the referenced entities reference in turn "heavy" object graphs, this causes a very significant memory usage increase, since references to detached entities will remain in the cache. This is even more evident when using disk persistence with ehcache, since the full object graphs are serialized to disk. This could be easily improved (correct me if I'm wrong) by storing ONLY entity identifiers in the QueryKey instead of full entities, since all the query really needs is the identifier property. The memory usage would decrease dramatically. So far the workaround we've found is explicitly using restrictions that reference identifiers instead of properties in HQL queries, however this is not particularly elegant, and still leaves open the issue with Criteria queries. The same cannot be done without criteria.createCriteria() which generates an unnecessary join in most cases. -- 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, 12 months

6
10
0 / 0

[Hibernate-JIRA] Created: (HHH-6975) SQL error "expected NUMBER got BINARY" when calling AuditReader.find()

by Verrier (JIRA)

SQL error "expected NUMBER got BINARY" when calling AuditReader.find() ---------------------------------------------------------------------- Key: HHH-6975 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6975 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 3.6.5 Environment: Hibernate version: 3.6.5.Final Database platform: Oracle Application server: Weblogic 11g Reporter: Verrier Priority: Blocker When calling AuditReader.find(), I've a SQLError "expected NUMBER got BINARY". It seams it comes from Java class EntitiesAtRevisionQuery.java (line 91). It tries to compare the content of the column "REVTYPE" in the audit table (which is of NUMBER type) to the content of the constant "RevisionType.DEL" (which is of BYTE type). I think it could be fix by replacing "RevisionType.DEL" with "RevisionType.DEL.getRepresentation()" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6973) Reduce cache entry size by using long[] instead of ArrayList<Long> for queries and collections values

by Adrien (JIRA)

Reduce cache entry size by using long[] instead of ArrayList<Long> for queries and collections values ----------------------------------------------------------------------------------------------------- Key: HHH-6973 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6973 Project: Hibernate ORM Issue Type: Improvement Components: caching (L2) Affects Versions: 3.6.9 Reporter: Adrien Priority: Minor Attachments: patch.zip A lot of cacheable queries and cacheable collections are stored in L2 as an ArrayList of the primary key of the target entities. Most of the time, this primary key are Integer or Long. By storing this value as primitive array (int[] or long[]), I was able to divide the size of the entry cache by two on a classic web project. There is no thousands of Integer instances in memory anymore (32 bytes per instance), but a clean, compact array (4 or 8 x array size bytes). Since Hibernate cache is the main use of the memory in a classic ORM project, it allows to have more queries and collections in memory, greatly improving the use of the cache. I provide a sample patch of the correction for Integer primary key. It still needs a lot of improvements (Long primary key, optimisation, better dectection of the primary key type, unstructured storage in cache), but it is the general idea. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 12 months

1
0
0 / 0

[Hibernate-JIRA] Created: (METAGEN-64) Normal class in hierarchy breaks metamodel

by Robin Sander (JIRA)

Normal class in hierarchy breaks metamodel ------------------------------------------ Key: METAGEN-64 URL: http://opensource.atlassian.com/projects/hibernate/browse/METAGEN-64 Project: Hibernate Metamodel Generator Issue Type: Bug Affects Versions: 1.1.1.Final Environment: HIbernate 3.6.3.Final, PostgreSQL 8.4, Java 6 Reporter: Robin Sander Assignee: Hardy Ferentschik Priority: Minor If an entity class extends a normal class which in turn extends another entity or a mapped superclass the generated meta model doesn't reflect this hierarchy. -- 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, 12 months

2
11
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2012