[Hibernate-JIRA] Created: (BVAL-213) Convert persistence storage exception into Bean Validation exceptions
by Emmanuel Bernard (JIRA)
Convert persistence storage exception into Bean Validation exceptions
---------------------------------------------------------------------
Key: BVAL-213
URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-213
Project: Bean Validation
Issue Type: New Feature
Components: spec-general
Reporter: Emmanuel Bernard
This is not a problematic of Bean Validation per se but one of the issue people are facing is inconsistency in constraint reporting.
For example, the database can raise a some kind of unique constraint exception (specific to each vendor usually). It would be ideal to get it converted into a @Unique constraint exception as defined by Bean Validation.
Said differently by Christian
{code}I'd rather see improvement of message propagation/mapping when an integrity rule inside the database has been violated. Like, turning a fatal database transaction exception (JDBCException wrapped etc.) into a clean error message, with a strong and stable mapping across DBMS products. If a UNIQUE constraint has been violated at the database level, I'd like to catch it and turn it into a Bean Validation error for my client.
We have discussed this >5 years ago and at that time there was just no way to really guarantee that a JDBCException can tell you what the real cause of the problem was. Nobody standardized or required that the catalog name of the violated constraint is included so you couldn't map it. Maybe that's possible now. If not, at least the generic ConstraintViolationException should be an SPI of Bean Validation that JPA providers can throw.{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
13 years, 3 months
[Hibernate-JIRA] Created: (HHH-6162) SessionFactory in QueryKey
by Pawel Omelko (JIRA)
SessionFactory in QueryKey
--------------------------
Key: HHH-6162
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6162
Project: Hibernate Core
Issue Type: Bug
Affects Versions: 4.0.0.Alpha2, 3.6.3, 4.0.0.Alpha1, 3.6.2
Environment: Hibernate 3.6.2, Postgresql 8.3
Reporter: Pawel Omelko
Priority: Blocker
I guess that after improvement HHH-5138, a ManyToOneType.java (and many other types) has reference to SessionFactory (by TypeFactory.TypeScope scope field). And now QueryKey, which contains Type[] positionalParameterTypes field, contains also SessionFactory - eg. ManyToOneType. So now we can find SessionFactory in QueryCache elements, which unnecessarily increase memory usage. There is another problem when cache replication is used (ehcache via RMI), I've got an exception during SessionFactory deserialization in receiver node:
Apr 27 06:17:58 WARN net.sf.ehcache.distribution.RMIAsynchronousCacheReplicator:320 - Unable to send message to remote peer. Message was: null
Apr 27 06:17:58 java.lang.NullPointerException
Apr 27 06:17:58 at java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768)
Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryObjectFactory.getNamedInstance(SessionFactoryObjectFactory.java:159)
Apr 27 06:17:58 at org.hibernate.impl.SessionFactoryImpl.readResolve(SessionFactoryImpl.java:753)
Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Apr 27 06:17:58 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
Apr 27 06:17:58 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
Apr 27 06:17:58 at java.lang.reflect.Method.invoke(Method.java:597)
Apr 27 06:17:58 at java.io.ObjectStreamClass.invokeReadResolve(ObjectStreamClass.java:1061)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1762)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1871)
Apr 27 06:17:58 at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1753)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
Apr 27 06:17:58 at java.io.ObjectInputStream.readArray(ObjectInputStream.java:1667)
Apr 27 06:17:58 at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1323)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1947)
Apr 27 06:17:58 at java.io.ObjectInputStream.defaultReadObject(ObjectInputStream.java:480)
Apr 27 06:17:58 at org.hibernate.cache.QueryKey.readObject(QueryKey.java:192)
--
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, 3 months