Amen, on all points. Been there, done that, never again.
On Thu, 24 Feb 2005 08:42:45 -0700, Larry Meadors <[EMAIL PROTECTED]> 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 > <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > 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 > > <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > 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 <[EMAIL PROTECTED]> > > > 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" <[EMAIL PROTECTED]> > > > > To: ibatis-user-java@incubator.apache.org, "Tim Christopher" > > > <[EMAIL PROTECTED]> > > > > 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 > > > > > <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > > 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 > > > > > > > > > > > > > > > > > > > > > > > > >
