I think that this might be an issue on which we'll have to agree to
disagree.
I personally think that a database exception is recoverable. Especially
in the case of large applications in which several databases can be used
for different purposes. If one goes down, large portions of the
applicati
public interface UserType {
public Object replace(Object original, Object target, Object owner)
throws HibernateException;
}
--
Christian Bauer
+49 171 455 66 53
callto://christian-bauer
Hibernate
[EMAIL PROTECTED]
http://hibernate.org
JBoss Inc
[EMAIL PROTECTED]
http://jboss.com
Hi Scott,
Actually we kinda think the opposite :-) and we're not alone (see the
Spring exception wrapper for example).
We consider checked exceptions as receverable contractual issues.
HibernateException have to be treated as not recoverable and the Tx has
to be rollbacked. As stated by the EJB s
On Jan 24, 2005, at 12:45 AM, <[EMAIL PROTECTED]> wrote:
I searched the mailing list and I couldn’t find the reason for why the
HibernateException was changed to a RuntimeException. If a failure
occurs while persisting an object, for example if the database becomes
unavailable, it would seem th
I searched the mailing list and I couldn’t find the
reason for why the HibernateException was changed to a RuntimeException. If a failure occurs while persisting an object, for example if the database becomes
unavailable, it would seem that the client should be forced to handle the
failure
I think that collections of non-entities is actually working now.
FooBarTest.testQuery() no longer errors, and if fails just at the end
when it is doing a very complex query. I've cleaned up the tree
parsers a bit by taking advantage of ANTLR grammar rule parameters.
This is actually what
