June 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5069) Fix annotation documentation wrt setup

by Steve Ebersole (JIRA)

Fix annotation documentation wrt setup -------------------------------------- Key: HHH-5069 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5069 Project: Hibernate Core Issue Type: Bug Components: annotations, documentation Affects Versions: 3.5.0-Final Reporter: Steve Ebersole Fix For: 3.5.x http://in.relation.to/Bloggers/Hibernate350FinalRelease#comment15080 The annotation guide seems to document incorrectly the steps getting started in terms of copying jars from the distribution to the developer project. Specificially it appears to call call for copying: * hibernate-annotations.jar (part of hibernate3.jar) * lib/hibernate-comons-annotations.jar (part of hibernate3.jar) * lib/hibernate-jpa-2.0-api.jar (actually under jpa/, not lib/) -- 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
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5218) Provide a new "pooled value" based optimizer which interprets the database value as the low boundary instead of upper boundary

by Steve Ebersole (JIRA)

Provide a new "pooled value" based optimizer which interprets the database value as the low boundary instead of upper boundary ------------------------------------------------------------------------------------------------------------------------------ Key: HHH-5218 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5218 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.2, 3.6 Splitting up HHH-3608 into its individual tasks. This part deals with the assumption made in PooledOptimizer that the sequence value is the upper boundary of the current range of values. This is an assumption and the other assumption that the value is the lower boundary is just as valid, so provide for both by adding a new optimizer. The new optimizer class will be org.hibernate.id.enhanced.OptimizerFactory.PooledLoOptimizer and its short name will be "pooled-lo". The already existing one will remain the default, but I will add a config option to allow users to specify which to use per setup ('hibernate.id.prefer_pooling_lo_values'). -- 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
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5131) SchemaExport drop fails if constraint names change

by Strong Liu (JIRA)

SchemaExport drop fails if constraint names change -------------------------------------------------- Key: HHH-5131 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5131 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.3.2 Environment: PostgreSQL Reporter: Strong Liu Fix For: 3.3.x, 3.5.x for PostgreSQL dialect, it doesn't use cascade to drop tables, this may causes error when it drops the constraints. for example, there is a table A with a FK which name is "123456" but schemaUpdate uses a different FK name to drop it, then fails, then it tries to drop Table A, fails again :( HB-540 was reported a long ago, and Gavin added a comment "We can't apply this patch since older versions of Postgres don't support the cascade syntax." but I don't think it is still a problem( it was a comment added in 2003), as even the PostgreSQL 7.x support this syntax -- 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
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5032) Setting LockModeType.OPTIMISTIC_FORCE_INCREMENT defaults to only OPTIMISTIC

by Carlos Vara (JIRA)

Setting LockModeType.OPTIMISTIC_FORCE_INCREMENT defaults to only OPTIMISTIC --------------------------------------------------------------------------- Key: HHH-5032 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5032 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.0-CR-2 Environment: Hibernate Core 3.5.0-CR-2, Hibernate Validator 4.1 Snapshot, Spring 3.0.1, JPA2 Reporter: Carlos Vara Using EntityManager.lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT) doesn't change lock type, and version doesn't get updated on transaction commit. The following code: System.out.println("PRE lock mode: " + this.entityManager.getLockMode(an)); this.entityManager.lock(an, LockModeType.OPTIMISTIC_FORCE_INCREMENT); System.out.println("POST lock mode: " + this.entityManager.getLockMode(an)); Outputs: PRE lock mode: OPTIMISTIC POST lock mode: OPTIMISTIC Debugging AbstractLockUpgradeEventListener.upgradeLock, the reason is it doesn't upgrade it because previous lock mode is "READ" (whose level is 5), and OPTIMISTIC_FORCE_INCREMENT has level 4, so it doesn't trigger the update. I'm not sure about Hibernate's LockMode, but I think that OPTIMISTIC_FORCE_INCREMENT is a bit more restrictive than just OPTIMISTIC, so the locking type should be upgraded. -- 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

5
20
0 / 0

[Hibernate-JIRA] Created: (HHH-5208) Oracle 11g R2 RAC - Test SequenceIdentityTest fails because first value of sequence is "2"

by Strong Liu (JIRA)

Oracle 11g R2 RAC - Test SequenceIdentityTest fails because first value of sequence is "2" ------------------------------------------------------------------------------------------ Key: HHH-5208 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5208 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.5.x Environment: Oracle 11g R2 (RAC) Reporter: Strong Liu Starting with Oracle 11g R2 (RAC), the behavior of the CREATE TABLE statement has changed, when creating a conventional table in a database created with the default options then the initial segment is not created until the first row is inserted into the table. see http://download.oracle.com/docs/cd/E11882_01/server.112/e10595/tables002.... for more details. We found a potential downside to this change : The sequences created as default ( start with 1 increment by 1) are not staring with '1′ when used in insert query script, Instead they are starting with 2 or 4, this can not be changed even explicitly tell Oracle that the first value is "1". In another words, when using Hibernate with Oracle 11g R2 (RAC), if the ID generator class is "sequence-identity", the first value is NOT 1. Two ways to work around this issue: 1. Using another ID generator class. 2. Disable deferred segment creation of Oracle by setting the initialization parameter DEFERRED_SEGMENT_CREATION to FALSE. The new clauses SEGMENT CREATION DEFERRED and SEGMENT CREATION IMMEDIATE are available for the CREATE TABLE statement. These clauses override the setting of the DEFERRED_SEGMENT_CREATION initialization parameter. -- 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

4
10
0 / 0

[Hibernate-JIRA] Created: (HHH-5210) Query Cache effective only after closing the session that created the cache

by Strong Liu (JIRA)

Query Cache effective only after closing the session that created the cache --------------------------------------------------------------------------- Key: HHH-5210 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5210 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.5.x Reporter: Strong Liu When using a query which is marked as cacheable, Hibernate caches both the query and the timestamp in the cache, but uses two different timestamps for that. When retrieving a query from the cache, it first compares the timestamp of the cached query with the timestamp of the current session (UpdateTimestampsCache.isUpToDate()): if ( lastUpdate.longValue() >= timestamp.longValue() ) { return false; } The problem is that the timestamp for the current session is always lower than cache's timestamp if the cache was created with the same session, causing the result of the method to be "false", discarding the cache results and hitting the database. It's not clear where the bug is, but it's worth looking at some considerations: 1) Why is it comparing the cache's timestamp with session's timestamp? The cache itself can expire the data via timeout and Hibernate should expire the data if any relevant table was changed (both are happening). Besides, I wasn't able to think of a single use case where the cached data could be considered "outdated" just because its timestamp is higher than the current session's timestamp (meaning that they are newer than the session). 2) The javadoc for the SessionImplementor.getTimestamp() says: "System time before the start of the transaction" So, someone consuming this method can assume that this timestamp is related to the transaction. If the timestamp was related to the transaction, then the cache's timestamp would never be higher than session's. Then, this comparison would make sense, to not return something which would never happen and is probably wrong. So, it's up to the developers to decide what's wrong: - JavaDoc + the logic to get a timestamp which is used when creating the query cache - getTimestamp() value + UpdateTimestampsCache.isUpToDate logic + other places relying in the wrong return value -- 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
7
0 / 0

[Hibernate-JIRA] Created: (HHH-5078) JPA criteria query numeric expressions produce wrong result (due to wrong bracketing)

by Christoph Gerkens (JIRA)

JPA criteria query numeric expressions produce wrong result (due to wrong bracketing) ------------------------------------------------------------------------------------- Key: HHH-5078 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5078 Project: Hibernate Core Issue Type: Bug Components: entity-manager, query-criteria Affects Versions: 3.5.0-Final Environment: Hibernate-Core 3.5.0-Final, all database platforms Reporter: Christoph Gerkens The combination of quot and diff results in wrong SQL code. E.g.: (2 - 1) / 2 should be evaluated to 0.5 not 1.5 ( which is 2 - (1 / 2). JUnit 4 Test: @Test public void testJpaCriteriaApiQuoteAndDiff() { CriteriaBuilder cb = em.getCriteriaBuilder(); CriteriaQuery<Number> query = cb.createQuery(Number.class); query.from(SystemUser.class); // entity type doesn't matter, but must contain at least one entry for this test case. query.select( // (2 - 1) / 2 cb.quot( cb.diff( cb.literal(BigDecimal.valueOf(2.0)), cb.literal(BigDecimal.valueOf(1.0))), BigDecimal.valueOf(2.0))).distinct(true); Number result = em.createQuery(query).getSingleResult(); assertEquals(0.5d, result.doubleValue(), 0.1d); // (2 - 1) / 2 = 0.5 } -- 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

4
11
0 / 0

[Hibernate-JIRA] Created: (HHH-5173) hql - average returns double but looses the decimal part

by Sébastien Peters (JIRA)

hql - average returns double but looses the decimal part -------------------------------------------------------- Key: HHH-5173 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5173 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.0-Final Environment: Database driver: hsqldb OS: Mac-Os Hibernate: 3.5.0-Final Reporter: Sébastien Peters HQL: select avg(r.rating) from Review r for the values 2,2,2,1,2 it should return 1.8 instead of 1.0 type of rating: integer -- 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

4
16
0 / 0

[Hibernate-JIRA] Created: (HHH-4966) Entity Manager bug with ParameterExpressionImpl

by jean-claude cote (JIRA)

Entity Manager bug with ParameterExpressionImpl ----------------------------------------------- Key: HHH-4966 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4966 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-CR-1 Reporter: jean-claude cote Emmanuel There seems to be a bug with the ParameterExpressionImpl class when rendering. If you create a criteria query using a ParameterExpression instance in multiple places in your query the rendering of this query will produce multiple pram0, param1, param2 for the same ParameterExpression instance. We fixed this bug by augmenting the RenderingContext interface with generateParameterName(Expression<?> exp). With this information the rendering context can give back the same jpaqlParameterName for the same ParameterExpression instance. All it has to do is do a lookup in its explicitParamtermapping map. Thanks Jean-Claude -- 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
8
0 / 0

[Hibernate-JIRA] Created: (HHH-5217) Minimize double sequence value reads in PooledOptimizer

by Steve Ebersole (JIRA)

Minimize double sequence value reads in PooledOptimizer ------------------------------------------------------- Key: HHH-5217 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5217 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.2.6 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.2, 3.6 Splitting up HHH-3608 into its individual tasks. This part is about minimizing the double sequence value reads. Really the double read is only needed when we are initializing the optimizer *and* the first read gave us the initialValue (perhaps this should be anything less than the increment?). -- 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
2
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2010