Hi,
Apologies is this question is trivial for the group but I'm very new
to using iBATIS.
I've managed to successfully integrate iBATIS into my Struts
application, using a structure much like the sample JPetStore project
- this acted as my tutorial.
Can someone let me know if it is possible for
Yah. Anad Fida was asking before about how to use queryForMap with column
parameters in a Complex Property. Branon Goodin told him that it wasn't
possible. His suggestion was to "query your accounts first and then iterate
through the list using the queryForMap." However in my case if my first
Co
you should not specify your primary key in the update values of your
update statement. It should be part of your where criteria.
BAD:
UPDATE SOMETABLE
(somePrimaryKey,columnA,columnB,columnC)
VALUES(#somePrimaryKey#,#'valueA#,#valueB#,#valueC#)
WHERE somePrimaryKey = 1
GOOD:
UPDATE SOMETABLE
(c
Sorry, I should have mentioned that I was talking about an
insertion... Currently it is possible for a user to create a new
Module by specifying a module code, name, etc.. The module code is a
primary key and must be a unique value, though it must match with a
value stored in another system so ca
Can you perform the insert, and capture the error that comes back on the
SQLException?
-Original Message-
From: Tim Christopher [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 23, 2005 11:06 AM
To: ibatis-user-java@incubator.apache.org
Subject: Re: Duplicate Key in Db
Sorry, I shoul
Tim,
I'd want to design it so that the database assigns the primary keys.
It's the best way to do it IMHO. Any object to be persisted is checked
for a primary key. If it's null, you do an insert; if it's not null,
you want an update. The database assigns primary keys and can use a
sequence
"The module code is a primary key and must be a unique value, though
it must match with a value stored in another system so can not be an
auto-increment value."
I don't think his situation would allow for that.
Brandon
> I'd want to design it so that the database assigns the primary keys.
> It's
I'll get my coat...
:-[
"The module code is a primary key and must be a unique value, though
it must match with a value stored in another system so can not be an
auto-increment value."
I don't think his situation would allow for that.
Brandon
I'd want to design it so that the database assigns th
There is no way a framework would be able to accomplish that apart
from exactly what you stated. You should assure the verasity of the
object you want to insert before you attempt to insert it. That will
always happen against the databsae even if you created a memory
resident object identity layer.
So what happens if you have a SQL statement that inserts data into
serveral tables. Every change to the database would require you to
reevaluate what checks (select statements) need to be done to ensure a
situtation where it is possible for duplicate primary keys to occur in
each table. I do not
You can do that now. Maybe I'm missing something?
The Ibatis insert() statement throws a SQLException.. When you perform
your insert, catch the SQLException make sure it's a unique constraint
violation and move on...
-Original Message-
From: Tim Christopher [mailto:[EMAIL PROTECTED]
Sen
Have you considered a stored procedure for this?
If the rules surrounding the data are as complex and fluid as they
sound, that may be the easiest way to centralize the managment of
them.
Larry
On Wed, 23 Feb 2005 18:54:02 +, Tim Christopher
<[EMAIL PROTECTED]> wrote:
> So what happens if y
>> 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?
>
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 "Run
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
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,
Would you say that this better:
" Form Model (Beans or Dynamaps :-P ) should not depend on the DAO in
any way. "
I kind of draw the sqlmap's xml file as a Domain Model. Ex:
Customers.XML I would call a Domain Model. (Then use a DTO to go to Form
Model. Form Model maps to the View's fields but
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 integra
I'll have to check that (I had to run home), thanks.
>-- Original Message --
>Reply-To: ibatis-user-java@incubator.apache.org
>Date: Mon, 21 Feb 2005 22:32:46 + (GMT)
>From: "Kris A. Jenkins" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>Subject: Re: cacheModel still hitting database
>To:
I agree with larry... don't get nuts on this thing. Simple is better.
This is not an abnormal problem. Using an exception is BAD policy.
Exceptions are generic and meant to be thrown and graceful recovery.
This does not fall into thos categories. Exceptions should not be used
for control flow. Tak
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
My probably goes a little against the grain of what you are saying,
though I've only just read your comments...
What I've done is to extend the framework to allow iBATIS to return an
int for insertions calls, then created a constants file (as a HashMap)
to turn returned values into entries from th
You are simply performing error interpreatation for user consumption.
So, no matter what SQLException gets thrown it will simply display an
error to the user. However, i would not recommend that you get into
the practice of deciding how to proceed based upon the type of
SQLException that is being t
eeek... recovery via exceptions is an anti-pattern. This is not an
exception issue. It is a validation issue.
Brandon
On Wed, 23 Feb 2005 11:54:59 -0500, Akins, Greg <[EMAIL PROTECTED]> wrote:
> Can you perform the insert, and capture the error that comes back on the
> SQLException?
>
> -Or
I agree with larry... don't get nuts on this thing. Simple is better.
This is not an abnormal problem. Using an exception is BAD policy.
Exceptions are generic and meant to be thrown and graceful recovery.
This does not fall into thos categories. Exceptions should not be used
for control flow. Tak
I understand there is a way to use the IN-keyword by giving a List of
parameters to a query as shown at
http://issues.apache.org/jira/browse/IBATIS-38, but what if I need to
give the query other parameters too? I would like to give the query a
Map where one value is the List for the IN-clause, and
26 matches
Mail list logo
