ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean-Francois Poilpret" <jfpoilp...@hcm.vnn.vn>
Subject RE: Duplicate Key in Db
Date Thu, 24 Feb 2005 14:25:43 GMT
The fact is JDBC is done this way.
You get an SQLException for _whatever_ error occurred, and there is no
portable way to determine the true meaning of that exception, in particular
when this exception may be relevant for you to handle, in particular
problems of unique index (I did not say primary key) or referential
integrity constraints.

So one must find one way or another to deal with that.
Although I am not a Spring aficionado, I think the Spring DAO offers a good
possibility to deal with this, by introducing more focused exceptions
related to the DB and "translating" SQLExceptions into this hierarchy of
exceptions. The translation is done by Spring beans that are smart enough to
manage different databases without changing any code.
I do not think Spring has a lame design to this regard.

I completely agree that exceptions SHOULD NOT be used for flow control (I
have to struggle everyday against that), but sometimes you have no much
choice, because of the libraries you use (in particular JDBC, but you could
find many other examples in Java libs).

Just my 2c

Cheers

	Jean-Francois

-----Original Message-----
From: Brandon Goodin [mailto:brandon.goodin@gmail.com] 
Sent: Thursday, February 24, 2005 11:08 AM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db

To be honest... that sounds like a bad decision. Using database error
codes to determine application flow is very subjective and dangerous.
I could see passing a human readable error up to the user of the app
and using a lookup of some sort to make assist in the process. But, I
would NEVER base my application flow on the database error codes being
passed back. Sorry, but that seems like a really lame idea.

Brandon


On Thu, 24 Feb 2005 07:35:18 +0700, Jean-Francois Poilpret
<jfpoilpret@hcm.vnn.vn> wrote:
> Guys,
> 
> Such an "ugly" path is what Spring DAO does. I don't think it is so ugly,
as
> long as there are no hard-coded error codes, but something more
> parameterizable like you have in Spring.
> 
> So the solutions would be:
> 1- use Spring with SqlMaps
> 2- or take from Spring the interesting bits and integrate them into your
own
> design. On that one, I think the iBATIS DAO FW should provide this kind of
> thing out of the box (but not necessarily the SqlMaps FW, although it
would
> be good to have that here as well)
> 
> Cheers
> 
>         Jean-Francois
> 
> -----Original Message-----
> From: Larry Meadors [mailto:larry.meadors@gmail.com]
> Sent: Thursday, February 24, 2005 4:02 AM
> To: ibatis-user-java@incubator.apache.org
> Subject: Re: Duplicate Key in Db
> 
> Man guys, this is going down a really ugly path.
> 
> What happens when you get a new driver, and the message changes from
> "Invalid key" to "Duplicate key"? Your app is broken. This path to me
> seems to be fraught with peril. ;-)
> 
> I still say that the stored procedure is the safest, simplest,
> fastest, and most controllable route to take.
> 
> Larry
> 
> On Wed, 23 Feb 2005 14:48:24 -0600, Brent Worden <brent@worden.org> wrote:
> > You might also try to examine the errorCode property of the
> NestedSQLException or the wrapped SQLexception.  It should hold a vendor
> specific code that identifies the type of database error.
> >
> > ----- Original Message -----
> > From: "Brice Ruth" <bdruth@gmail.com>
> > To: ibatis-user-java@incubator.apache.org, "Tim Christopher"
> <tim.christopher@gmail.com>
> > Subject: Re: Duplicate Key in Db
> > Date: Wed, 23 Feb 2005 14:32:25 -0600
> >
> > >
> > > I think you need to catch a DaoException, and check its cause. If its
> > > cause is a NestedSqlException, you'll need to interrogate that to
> > > determine what the "real" cause was. In your case, it appears a
> > > generic exception is thrown by the JDBC driver
> > > (com.borland.datastore.driver.SqlState), with a "Runtime Error" -
> > > you'll probably need to parse for "Duplicate key" to determine if
> > > that's what's being thrown.
> > >
> > > I've had to do something similar ... it certainly isn't elegant, at
> > > least not the way I did it! Maybe someone else has a better
> > > suggestion.
> > >
> > >
> > > On Wed, 23 Feb 2005 20:23:23 +0000, Tim Christopher
> > > <tim.christopher@gmail.com> wrote:
> > > > >> You can do that now.  Maybe I'm missing something?
> > > > >> The Ibatis insert() statement throws a SQLException.. ..
> > > >
> > > > Below is the first part of stack dump that is triggers by the failed
> > > > insertion, so should I be catching a DaoException or
> > > > NestedSQLException?...  Or is there anything else I can do?
> > > >
> > > > >>>>>>
> > > > StandardWrapperValve[action]: Servlet.service() for servlet action
> > > > threw exception
> > > > com.ibatis.dao.client.DaoException: Failed to update - id
> > > > [insertModule] - parameterObject [com.socs.dto.Module@b9b8d0].
Cause:
> > > > com.ibatis.common.jdbc.exception.NestedSQLException:
> > > > --- The error occurred in
> com/socs/persistence/sqlmapdao/sql/Module.xml.
> > > > --- The error occurred while applying a parameter map.
> > > > --- Check the insertModule-InlineParameterMap.
> > > > --- Check the statement (update failed).
> > > > --- Cause: com.borland.datastore.driver.SqlState: Runtime Error:
[line
> > > > 1, col 6] Duplicate key value for $UNIQUE$1 sort order in "MODULE".
> > > > Caused by: com.borland.datastore.driver.SqlState: Runtime Error:
[line
> > > > 1, col 6] Duplicate key value for $UNIQUE$1 sort order in "MODULE".
> > > > <<<<<<
> > > >
> > > > Tim Christopher
> > > >
> >
> >
> 
>



Mime
View raw message