July 2010 - hibernate-issues - Jboss List Archives

[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

14 years, 5 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

14 years, 5 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

14 years, 5 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

14 years, 5 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

14 years, 5 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

14 years, 5 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5178) Unit tests in org.hibernate.test.immutable fail on mssql and sybase due to keyword used for table and column name

by Gail Badner (JIRA)

Unit tests in org.hibernate.test.immutable fail on mssql and sybase due to keyword used for table and column name ----------------------------------------------------------------------------------------------------------------- Key: HHH-5178 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5178 Project: Hibernate Core Issue Type: Bug Components: testsuite Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.x, 3.6 Failing due to "plan" used for table and column name. -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5186) update db profiles id and jdbc properties' name to use dballocator

by Strong Liu (JIRA)

update db profiles id and jdbc properties' name to use dballocator ------------------------------------------------------------------ Key: HHH-5186 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5186 Project: Hibernate Core Issue Type: Task Components: build Reporter: Strong Liu Assignee: Strong Liu [dballocator|https://docspace.corp.redhat.com/docs/DOC-29725] uses different DB names with our profiles' id to use this in our hudson build, our profile id should be updated. for example, there is a DB profile with id "mssql2005", it will be changed to "mssql-2005". for full DB list, please refer to [https://svn.devel.redhat.com/repos/jboss-soa/trunk/qa/dballocator/resourc...] -- 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

14 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3377) this time its h2 : foncusion of DECIMAL and NUMERIC column types

by Jan Baumann (JIRA)

this time its h2 : foncusion of DECIMAL and NUMERIC column types ----------------------------------------------------------------- Key: HHH-3377 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3377 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: H2 1.0.72, Hibernate 3.2.6 Reporter: Jan Baumann Analogous to HHH-2582 when trying to persist a BigDecimal object, hibernate throws a org.hibernate.HibernateException stating "Wrong column type in [...]. Found: decimal, expected: numeric" I checked the H2Dialect.java file, and as had been described for the MySQLDialect.java the following line was present : registerColumnType(Types.NUMERIC, "numeric"); Since H2 doesn't have a numeric type I tried the solution found for HHH-2582 and changed the line mentioned above to registerColumnType( Types.NUMERIC, "decimal($p,$s)" ); This seems to do the trick. -- 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

14 years, 5 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5006) hibernate.globally_quoted_identifiers=true and Annotations tests

by Stephan Palm (JIRA)

hibernate.globally_quoted_identifiers=true and Annotations tests ---------------------------------------------------------------- Key: HHH-5006 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5006 Project: Hibernate Core Issue Type: Bug Components: annotations, core Affects Versions: 3.5.0-CR-2 Environment: eclipse galileo jdk 1.6 Server library JBoss 6.0 M2 (actually I don`t think you need any of this information) Reporter: Stephan Palm If I use hibernate.globally_quoted_identifiers=true in order to quote all identifiers, then the mapping for column names breakes if I have a column with a @Column annotation but without a @Column(name=<COLUMN_NAME>). The mapping for the column name then turns out to be ``.　Which leads to problems when creating new tables. I was able to track the error back to {code} final String columnName = nameNormalizer.normalizeIdentifierQuoting( col.name() ); {code} from Ejb3Column.java. col.name() returns an empty string because the name was not explicitly set. nameNormalizer.normalizeIdentifierQuoting( col.name() ) then makes `` from the empty string. I was able to fix this problem by adding a guard to the nameNormalizer.normalizeIdentifierQuoting function: {code} if ( identifier.length() == 0) return null; {code} The function now looks like this: {code} public String normalizeIdentifierQuoting(String identifier) { if ( identifier == null ) { return null; } if ( identifier.length() == 0) return null; // Convert the JPA2 specific quoting character (double quote) to Hibernate's (back tick) if ( identifier.startsWith( "\"" ) && identifier.endsWith( "\"" ) ) { return '`' + identifier.substring( 1, identifier.length() - 1 ) + '`'; } // If the user has requested "global" use of quoted identifiers, quote this identifier (using back ticks) // if not already if ( isUseQuotedIdentifiersGlobally() && ! ( identifier.startsWith( "`" ) && identifier.endsWith( "`" ) ) ) { return '`' + identifier + '`'; } return identifier; } {code} -- 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

14 years, 5 months

4
9
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2010