Mailing-List: contact ibatis-user-java-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ibatis-user-java@incubator.apache.org
Received-SPF: pass (hermes.apache.org: domain of bdruth@gmail.com designates
 64.233.184.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references;
        b=OesV7WO/6ZAiEgZ4LAEhnzQNqSFPe0oU4+zq148kndfaYdpBReauOYO1NOEihUlZU94DIz+ej4H6QT+oOm5Rw2/4CORPCVf2uVLpgco0OWcUg4NIZnhjBIC8QOdz9ziqGOSl7bWsBdtFluaWRYFy3d7dexwR1Rfynn+EFMRTBnI=
Message-ID: <bcd06dea05022408563d1b6e70@mail.gmail.com>
Date: Thu, 24 Feb 2005 10:56:40 -0600
From: Brice Ruth <bdruth@gmail.com>
Reply-To: Brice Ruth <bdruth@gmail.com>
To: ibatis-user-java@incubator.apache.org, lmeadors@apache.org
Subject: Re: Duplicate Key in Db
In-Reply-To: <a10a823c050224074253f00044@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
References: <2fe5ef5b05022320075b1035a2@mail.gmail.com>
	 <20050224142521.KHSF185555.HCM-MS-185@nbjeff>
	 <a10a823c050224074253f00044@mail.gmail.com>

Amen, on all points. Been there, done that, never again.


On Thu, 24 Feb 2005 08:42:45 -0700, Larry Meadors
<larry.meadors@gmail.com> wrote:
> IMO, the coolest thing about iBATIS is that if you want to go this
> way, that is fine. It is your application, so you can use whatever
> design you want to! :-)
> 
> This is my last comment on this: I have done this before, and would
> not do it again. My guess is that as you work through it, you are
> likely to encounter issues that will make it less and less attractive.
> 
> Larry
> 
> On Thu, 24 Feb 2005 21:25:43 +0700, Jean-Francois Poilpret
> <jfpoilpret@hcm.vnn.vn> wrote:
> > 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
> > > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>