April 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (BVAL-108) Implement a simpe performance test harness for Bean Validation

by Hardy Ferentschik (JIRA)

Implement a simpe performance test harness for Bean Validation -------------------------------------------------------------- Key: BVAL-108 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-108 Project: Bean Validation Issue Type: Task Components: ri-general Reporter: Hardy Ferentschik JPerf could for example be used. -- 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

13 years, 11 months

1
14
0 / 0

[Hibernate-JIRA] Created: (HHH-7003) Scale = 0 doesn't supported

by R. Gainullin (JIRA)

Scale = 0 doesn't supported --------------------------- Key: HHH-7003 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-7003 Project: Hibernate ORM Issue Type: Bug Components: envers Affects Versions: 4.0.1 Reporter: R. Gainullin If Audited entity consist Column with scale equals zero than Revision table create column with default scale value Entity class: @Entity @Audited public class Ent { @Column(scale=0,precision=20) private BigInteger field1; .... } For Postresql revision table: Table Ent_AUD{ field1 numeric(20, 2) } Probably error in file org.hibernate.envers.configuration.metadata.MetadataTools.java in method public static Element addColumn(...) { ... if (scale != 0) { column_mapping.addAttribute("scale", Integer.toString(scale)); } ... } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7253) NPE thrown by NaturalIdResolutionCache

by Strong Liu (JIRA)

NPE thrown by NaturalIdResolutionCache -------------------------------------- Key: HHH-7253 URL: https://hibernate.onjira.com/browse/HHH-7253 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Reporter: Strong Liu Fix For: 4.1.3 two tests are failling on oracle: {quote}org.hibernate.test.generatedkeys.seqidentity.SequenceIdentityTest.testSequenceIdentityGenerator Failing for the past 5 builds (Since #14 ) Took 0.68 sec. Error Message java.lang.NullPointerException Stacktrace java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.cache(NaturalIdXrefDelegate.java:454) at org.hibernate.engine.internal.NaturalIdXrefDelegate.cacheNaturalIdCrossReference(NaturalIdXrefDelegate.java:92) at org.hibernate.engine.internal.StatefulPersistenceContext$1.manageLocalNaturalIdCrossReference(StatefulPersistenceContext.java:1769) at org.hibernate.action.internal.AbstractEntityInsertAction.handleNaturalIdPreSaveNotifications(AbstractEntityInsertAction.java:184) at org.hibernate.action.internal.AbstractEntityInsertAction.<init>(AbstractEntityInsertAction.java:75) at org.hibernate.action.internal.EntityIdentityInsertAction.<init>(EntityIdentityInsertAction.java:55) at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(AbstractSaveEventListener.java:317) at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:287) at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:193) at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:126) at org.hibernate.test.generatedkeys.select.SelectGeneratorTest.testJDBC3GetGeneratedKeysSupportOnOracle Failing for the past 5 builds (Since #14 ) Took 0.87 sec. Error Message java.lang.NullPointerException Stacktrace java.lang.NullPointerException at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) at org.hibernate.engine.internal.NaturalIdXrefDelegate$NaturalIdResolutionCache.cache(NaturalIdXrefDelegate.java:454) at org.hibernate.engine.internal.NaturalIdXrefDelegate.cacheNaturalIdCrossReference(NaturalIdXrefDelegate.java:92) at org.hibernate.engine.internal.StatefulPersistenceContext$1.manageLocalNaturalIdCrossReference(StatefulPersistenceContext.java:1769) at org.hibernate.action.internal.AbstractEntityInsertAction.handleNaturalIdPreSaveNotifications(AbstractEntityInsertAction.java:184) at org.hibernate.action.internal.AbstractEntityInsertAction.<init>(AbstractEntityInsertAction.java:75) at org.hibernate.action.internal.EntityIdentityInsertAction.<init>(EntityIdentityInsertAction.java:55) at org.hibernate.event.internal.AbstractSaveEventListener.addInsertAction(AbstractSaveEventListener.java:317) at org.hibernate.event.internal.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:287) at org.hibernate.event.internal.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:193) at org.hibernate.event.internal.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:126) at {quote} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-7266) Move away from use of Enhydra developed DataSource for JTA testing

by Steve Ebersole (JIRA)

Move away from use of Enhydra developed DataSource for JTA testing ------------------------------------------------------------------ Key: HHH-7266 URL: https://hibernate.onjira.com/browse/HHH-7266 Project: Hibernate ORM Issue Type: Bug Components: testsuite Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.3 It really does not interop well with JTA TransactionManager which is unfortunately the whole point. Longer term would still like to look at leveraging IronJacamar, but it unfortunately still has its issues in terms of non-easy use in cases like ours. So for now, lets just resurrect the custom DataSource notion. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Commented: (HHH-1512) Problem to lock a row in a DB2 database with LockMode UPGRADE

by Steve Ebersole (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1512?page=com.atlassian.jira.plug... ] Steve Ebersole commented on HHH-1512: ------------------------------------- Strong, but what happens with rs? My guess is that: T1 : "select * from ck where id=3 with rr use and keep update locks" would acquire and hold U lock on the ck.id=3 row T2 : "select * from ck where id=3 with rr use and keep update locks" would block, waiting on T1, since T1 already has a U lock on the ck.id=3 row Also, if I understand correctly both (using rr or rs): T3 : "select * from ck where id=3" would acquire a read lock because U locks do not prevent concurrent read lock acquisition If yes, then that is exactly the behavior we want here for UPGRADE lock requests. > Problem to lock a row in a DB2 database with LockMode UPGRADE > ------------------------------------------------------------- > > Key: HHH-1512 > URL: https://hibernate.onjira.com/browse/HHH-1512 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: DB2 v8.2, Hibernate 3.1 and higher > Reporter: Peter Potthoff > Assignee: Steve Ebersole > Attachments: locks.txt > > Original Estimate: 1h > Remaining Estimate: 1h > > Using the LockMode UPGRADE to lock a row in the database, this will result in > a sql-statement: select ID from <schema>.<table> where ID =? and version =? for read only with rs > This statement produces a shared lock and cannot be used for pessimistic locking because > this kind of lock won't stop a concurrent thread from accessing the data. > The source of the class DB2Dialect.java was changed from release 1.34 to 1.35: > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > and from 1.33 to 1.34 > http://cvs.sourceforge.net/viewcvs.py/hibernate/Hibernate3/src/org/hibern... > Please take a look at: HHH-378 and http://forum.hibernate.org/viewtopic.php?t=954639&highlight=db2+lock+upgrade -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-2614) Blob Length Set to 255 By Default With Derby DB

by Sean Sylvis (JIRA)

Blob Length Set to 255 By Default With Derby DB ----------------------------------------------- Key: HHH-2614 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2614 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Environment: Apache Derby 10.2.2, Java 1.6.0 Reporter: Sean Sylvis When the (Hibernate) type "blob" is used in an object mapping file and a length is not specified, Hibernate converts this type as "blob (255)" to the Apache Derby database table definition. (This seems to be the same as the conversion behavior of a Java String to "varchar (255).") The same behavior results when using a CustomType that returns a Java SQL Types.BLOB. This is not the behavior I expected. Hibernate converts the same type as simply "blob" (which has a maximum length of 65535 bytes when no length is specified) when using MySQL version 5.0 (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html). Furthermore, the Derby specification (http://db.apache.org/derby/docs/10.2/ref/rrefblob.html) states that a blob type without a length value will default to a length of 2M-1 bytes. I could not find a length specification for the Java SQL Blob type (http://java.sun.com/javase/6/docs/api/), but the current default length does seem to conform to other Hibernate type standards. That is, if a length is not specified, the length defaults to the maximum length defined for that type by the database. -- 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

13 years, 11 months

9
13
0 / 0

[Hibernate-JIRA] Created: (HHH-7264) CLOB Length Set to 255 By Default With Derby DB

by ian mockford (JIRA)

CLOB Length Set to 255 By Default With Derby DB ----------------------------------------------- Key: HHH-7264 URL: https://hibernate.onjira.com/browse/HHH-7264 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.0.1 Environment: Derby 10.8.2.2 Reporter: ian mockford Attachments: hibernate-derby-test.zip When using JPA/Hibernate with a Derby DB, an @Lob annotation on a String gets truncated to a max of 255 chars. For example: private String message; @Lob @Column(name = "MESSAGE") public String getMessage() { return message; } Attached is a Maven project with a test case showing the problem; the Derby can be changed to H2 to make the tests pass. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7251) PostgreSQL Dialect not properly mapping SQL error codes for pessimistic lock exceptions.

by Bryan Varner (JIRA)

PostgreSQL Dialect not properly mapping SQL error codes for pessimistic lock exceptions. ---------------------------------------------------------------------------------------- Key: HHH-7251 URL: https://hibernate.onjira.com/browse/HHH-7251 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2, 3.6.10 Environment: PostgreSQL Reporter: Bryan Varner Attachments: Postgres91Dialect.java Using Hibernate-entitymanager in a JPA 2.0 environment, {code} Map<String, Object> params = new HashMap<String, Object>(); params.put("javax.persistence.lock.timeout", 0); entityManager.find(Foo.class, id, LockModeType.PESSIMISTIC_WRITE, params); {code} Will emit the proper SQL (with FOR UPDATE NOWAIT), however if the lock is not available, it results in throwing PersistenceException instead of PessimisticLockException or LockTimeoutException. I see that the SQL exception mapping code seems to be in a state of flux, where more of the handling is being pushed into delegates provided by the respective dialects. I highly approve of this approach, however it doesn't help me, since my transactions are being marked rollback only when a recoverable lock error (timeout) occurs. I'm attaching my solution, which is a quick and dirty custom dialect which properly maps PostgreSQL lock exceptions back to the proper Hibernate exceptions, which are then translated into the proper JPA exceptions. I know this issue existed in 3.6.10 (which is why I upgraded to 4.1.2 today). I do not know if the dialect-specific bits are in 3.6, but it appears the 'old' location for these types of error-code checks are in the SQLStateConversionDelegate, they could easily be added there. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-7258) NaturalIdCacheKey equals method doesn't work for primitive array types

by Steve Ash (JIRA)

NaturalIdCacheKey equals method doesn't work for primitive array types ---------------------------------------------------------------------- Key: HHH-7258 URL: https://hibernate.onjira.com/browse/HHH-7258 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.2 Environment: Hibernate 4.1.2 SQL 2008 Reporter: Steve Ash I have entities like (shorthand): {code} @Entity @Cache public class Parent { @Id private byte[] id; } @Entity @Cache @NaturalIdCache public class Child { @Id private byte[] id; @ManyToOne @NaturalId private Parent parent; @NaturalId private String name; } {code} So the naturalId is a compound key made up of a FK reference to the parent + the name of the child (i.e. for a single parent, all of the childrens names are unique). I always get a cache miss in the 2nd level cache when I try to load this by natural key using something like: {code} Parent p = ... // attached parent instance return sf.getCurrentSession() .byNaturalId(Child.class) .using("parent", p) .using("name", childName) .load(); {code} I stepped through the code and found that eventually an instance of {{NaturalIdCacheKey}} is built with a field {{naturalIdValues}}. In the Child instance above this naturalIdValues would be an array of size 2. The [0] element is a byte[] reference, and the [1] element is the child name string. While I can see in the debugger that my Child instance is present in the natural Id cache, the equals method on NaturalIdCacheKey just uses Array.equals on naturalIdValues. Thus, it does a reference equals on my primitive byte[] for the parent's PK value. While the values in the byte array are the same, they are different instances of course, and thus the reference equals returns false, and I never retrieve this from the natural id cache. Thinking I would be clever, I replaced this with an @Embeddable component that wrapped the byte[] and implemented my own equals, but Hibernate core _disassembles_ the component to build the naturalIdCacheKey which defeats my component and so we end up with the same problem. I have run in to a similar problem in HHH-7180 so clearly theres not too many of us that are using binary storage for GUIDs. Is everyone else just storing as 32byte strings? Or 22 byte case-sensitive coalation strings? Or an @embedded with two longs? I'll build a test case that replicates this at some point soon. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1018) Implement bridge that supports indexing for boolean queries based on lat and long instead of the whole grid

by Emmanuel Bernard (JIRA)

Implement bridge that supports indexing for boolean queries based on lat and long instead of the whole grid ----------------------------------------------------------------------------------------------------------- Key: HSEARCH-1018 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1018 Project: Hibernate Search Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Nicolas Helleringer This one should be trivial as it's a raw subset of what the current implementation does. We just need to make sure we use field names that are not polluted by HSSI thingies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 11 months

2
7
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 April 2012