March 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2426) Misleading logging messages when using ThreadLocalSessionContext

by Don Smith (JIRA)

Misleading logging messages when using ThreadLocalSessionContext ---------------------------------------------------------------- Key: HHH-2426 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2426 Project: Hibernate3 Type: Improvement Components: core Versions: 3.2.0.ga Reporter: Don Smith Priority: Minor The log messages printed out by TransactionFactoryFactory and SettingsFactory are misleading when using ThreadLocalSessionContext: 2007-02-09 21:49:58,581 INFO [org.hibernate.transaction.TransactionFactoryFactory:info] Using default transaction strategy (direct JDBC transactions) 2007-02-09 21:49:58,588 INFO [org.hibernate.transaction.TransactionManagerLookupFactory:info] No TransactionManagerLookup Configured (in JTA environment, use of read-write or transactional second-level cache is not recommended) 2007-02-09 21:49:58,590 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic flush during beforeCompletion(): disabled 2007-02-09 21:49:58,591 INFO [org.hibernate.cfg.SettingsFactory:info] Automatic session close at end of transaction: disabled This does not indicate that sessions will be closed after commit, which is the behavior when using ThreadLocalSessionContext. -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-682) @ForeignKey override of @MappedSuperclass

by Christian Bauer (JIRA)

@ForeignKey override of @MappedSuperclass ----------------------------------------- Key: ANN-682 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-682 Project: Hibernate Annotations Issue Type: New Feature Components: binder Reporter: Christian Bauer Put this @ManyToOne in a @MappedSuperclass: @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "CREATED_BY_USER_ID", nullable = false) // Ideally this foreign key should be ON DELETE SET NULL, however... // Hibernate can't rename these so subclasses would get the same FK constraint name. This doesn't // work, so we need to let Hibernate create a random identifier for these. We could fix this in the // DatabaseObjects.hbm.xml file but we can't even address it because the name is random. This sucks. // So we do a manual SET NULL|DEFAULT when userHome.remove() is called. // @org.hibernate.annotations.ForeignKey(name = "FK_WIKI_NODE_CREATED_BY_USER_ID") protected User createdBy; Now all subclasses get that foreign key constraint name in the database catalog, which isn't possible - constraint names have to be unique. -- 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, 7 months

6
7
0 / 0

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

by Franz Allan Valencia See (JIRA)

NPE when eager fetching joined component with native SQL query -------------------------------------------------------------- Key: HHH-3976 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3976 Project: Hibernate Core Issue Type: Bug Components: query-sql Affects Versions: 3.2.0.ga Reporter: Franz Allan Valencia See Priority: Critical Given a Hibernate Mapping with formula and named sql query, When accessing named sql query, NPE is thrown. This is basically a duplicae of HHH-2225. But since I cannot edit that to change it's Priority, I created a dupe. Feel free to close this if HHH-2225 has been edited to a higher priority. IMHO, it should be of a higher priority because AFAIK there are no decent workaround for 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3339) Query cache stops working after object save

by Alex Oleynikov (JIRA)

Query cache stops working after object save ------------------------------------------- Key: HHH-3339 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3339 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.6 Environment: Hibernate 3.2.6, MS SQL 2005 Database. Windows XP SP2 Reporter: Alex Oleynikov It seems like HB Query cache stops working as soon as given object type is being saved (it does not matter if it was save to existing object or insert of new object instance). The code looks like this. Where User is just a primitive POJO with couple of properties. // #1 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // #2 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // insert new User object user = new User(); user.setUserID((int)(Math.random() * Integer.MAX_VALUE)); user.setUserName("Ten"); session.beginTransaction(); session.save(user); session.getTransaction().commit(); // #3 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); // #4 query = session.createQuery("from User where userID = :id"); query.setCacheable(true); query.setParameter("id", 10); user = (User) query.list().get(0); >From MS SQL Profiler I can clearly see that no queries is executed for #2 (e.g. it hit the cache), but queries are executed for #3 and #4. From HB debug log I see following: For #2 Query (cache is hit) - correct: 06:54:25,337 DEBUG StandardQueryCache:102 - checking cached query results in region: org.hibernate.cache.StandardQueryCache 06:54:25,337 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,337 DEBUG StandardQueryCache:117 - returning cached query results During User insert: 06:54:25,368 DEBUG UpdateTimestampsCache:65 - Invalidating space [USERS], timestamp: 4967466866147328 For #3 Query: 06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888 06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date For #4 Query (or any subsequent query for this matter): 06:54:25,368 DEBUG StandardQueryCache:156 - Checking query spaces for up-to-dateness: [USERS] 06:54:25,368 DEBUG UpdateTimestampsCache:86 - [USERS] last update timestamp: 4967466866147328, result set timestamp: 4967466865061888 06:54:25,368 DEBUG StandardQueryCache:113 - cached query results were not up to date Please note the timestamp numbers for #4 query - even though I would expect query to be re-cached in #3, it still shows old timestamp. So I may think that when re-caching a query it does not update cache entry timestamp which is not up-to-date due to save(). -- 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, 7 months

5
8
0 / 0

[Hibernate-JIRA] Created: (HHH-3789) Allow for pluggable stats collection

by Patrick Moore (JIRA)

Allow for pluggable stats collection ------------------------------------ Key: HHH-3789 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3789 Project: Hibernate Core Issue Type: Patch Affects Versions: 3.5 Reporter: Patrick Moore Attachments: patch.txt I have a need to do more fine-grain stats collection. The current implementation does not allow for a replacement stats collection. This patch allows for the default stats code to be replaced with a custom implementation. -- 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, 7 months

2
10
0 / 0

[Hibernate-JIRA] Created: (HHH-3407) @TableGenerator does not increment pkColumnValue by allocationSize

by Dan Ciarniello (JIRA)

@TableGenerator does not increment pkColumnValue by allocationSize ------------------------------------------------------------------ Key: HHH-3407 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3407 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.6, 3.2.4 Environment: JBoss 4.2.3, RHEL4, JDK1.5 Reporter: Dan Ciarniello According to the JPA, the allocationSize attribute to @TableGenerator is "The amount to increment by when allocating id numbers from the generator" but the value is actually incremented by 1 regardless of allocationSize. The id is generated properly apparently according to the formula id = lastkeyval*allocationSize + i where 0<i<allocationSize The problems with this algorithm are: 1. One cannot tell what the next key value range is from the key table without knowing the allocationSize (minor) 2. If the allocationSize is reduced, already existing key values will be generated (major) 3. If two applications are configured with different allocation sizes, there will be an overlap in generated values (major) -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3709) Add StartRevision/EndRevison fileds to audit tables

by jason shi (JIRA)

Add StartRevision/EndRevison fileds to audit tables --------------------------------------------------- Key: HHH-3709 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3709 Project: Hibernate Core Issue Type: Improvement Components: envers Affects Versions: 3.4 Reporter: jason shi In Envers audit tables(eg:Person_Aud), two fields added:REV,REVTYPE When retrieve data at special REV, a sql with subselect executed: select a.id, a.REV, a.REVTYPE, a.name, a.surname, a.address_id from Person_AUD a where a.REVTYPE <> ? and a.id = ? and a.REV = (select max(b.REV) from Person_AUD b where b.REV <= ? and a.id = b.id) The sql performance is poor. I suggest adding StartRevision/EndRevison fileds to the audit tables,replace the REV field. The StartRevision equals the original REV field,EndRevision will be filledd when this record changed in next Revision. The new query sql will like this: select a.id, a.REV, a.REVTYPE, a.name, a.surname, a.address_id from Person_AUD a where a.REVTYPE <> ? and a.id = ? and a.StartRevision<=? and a.EndRevision>? -- 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, 7 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3766) Modify the queries executed to use the "end-revision" column, when available

by Adam Warski (JIRA)

Modify the queries executed to use the "end-revision" column, when available ---------------------------------------------------------------------------- Key: HHH-3766 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3766 Project: Hibernate Core Issue Type: Sub-task Reporter: Adam Warski Assignee: Adam Warski If the end-revision column is available, it should be use in queries which lookup revisions -- 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, 7 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HV-299) Annotation processor should check constraint annotation type declarations

by Gunnar Morling (JIRA)

Annotation processor should check constraint annotation type declarations ------------------------------------------------------------------------- Key: HV-299 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-299 Project: Hibernate Validator Issue Type: New Feature Components: annotation-processor Affects Versions: 4.1.0-Beta-1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik When visiting a custom constraint annotation type declaration, the AP should check the following: * proper declaration of groups(), message(), payload() * retention policy is RUNTIME * array of supported types must not be empty -- 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, 7 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-4769) In HQL, function ROUND always returns an Integer, it truncate the decimal part of Double number.

by Andrea Tunesi (JIRA)

In HQL, function ROUND always returns an Integer, it truncate the decimal part of Double number. ------------------------------------------------------------------------------------------------ Key: HHH-4769 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4769 Project: Hibernate Core Issue Type: Bug Components: core, entity-manager, query-hql Affects Versions: 3.3.2 Environment: hibernate 3.3.2, mysql-connector-java-5.1.7, database MYSQL 5. Reporter: Andrea Tunesi Priority: Blocker Running the query "select round(stTmpRiepCap.imponibile,1), round(stTmpRiepCap.ritImponibile,1) from StTmpRiepCap stTmpRiepCap", it always returns an Integer and it always truncate the decimal part of Double number ("stTmpRiepCap.imponibile" and "stTmpRiepCap.ritImponibile" are "java.lang.Double"). Example REAL VALUE - Imponibile: 1528.57 -- Ritenuta imponibile 266.13 VALUE RETURNED USING ROUND - Imponibile: 1528 -- Ritenuta imponibile 266 -- 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, 7 months

2
5
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 March 2010