Update / subquery
This statement returns an SQLException, saying I got an error in my SQL query. I can't seem to find one, so my question is: Is this possible in Ibatis? update id=updateAccount parameterClass=account UPDATE account SET email= #email#, first_name = #firstName#, last_name = #lastName#, password = #password#, role_id = (SELECT role_id FROM role WHERE rolename = #role#) WHERE username = #username# /update resultMap id=accountResult class=account result property=username column=username/ result property=email column=email/ result property=firstName column=first_name/ result property=lastName column=last_name/ result property=role column=rolename/ result property=password column=password/ result property=rootId column=folder_id/ /resultMap The error: Cause: java.sql.SQLException: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'SELECT role_id FROM role WHERE rolename = 'admin')
RE: JPetStore - BaseBean / BeanAction
Allright, I found it. ActionContext().getRequest().getSession().getServletContext() I looked over the getRequest() method. From: Lieven De Keyzer [EMAIL PROTECTED] Reply-To: ibatis-user-java@incubator.apache.org To: ibatis-user-java@incubator.apache.org Subject: JPetStore - BaseBean / BeanAction Date: Thu, 26 May 2005 17:24:23 + I'm building my webapplication with struts, using the BaseBean.java concept of JPetStore. In a class that extends the BaseBean class, I can access application, request, session etc. variables by doing: Map applicationMap = ActionContext.getActionContext().getApplicationMap(); Timer tasks = (Timer) applicationMap.get(tasks); Under the surface, the ApplicationMap makes getAttributes calls to the ServletContext. But now I want to use the getResourceAsInputStream method of ServletContext. Should I add a method to ApplicationMap? If I do this, it isn't really a 'Map' anymore, is it?
Re: transactions
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org, Brandon Goodin
[EMAIL PROTECTED]
Subject: Re: transactions
Date: Tue, 24 May 2005 13:40:04 -0600
Those update statements ARE in a transaction. But you should NEVER manage
transactions inside the DAO. The transaction in this case is taken care of
outside of the scope of this particular method (I believe in this case it
is
actually an automatic DAO transaction, so you might not find the calls to
start/commit/end).
So, what you mean is: I should make the transaction in my service layer, and
inside this transaction call the dao method. But if I change a method in my
DAO, to have multiple statements, I would also need to change my Service
class, to place the call in a transaction?
And how does one specify those automatic transactions?
Clinton
On 5/24/05, Brandon Goodin [EMAIL PROTECTED] wrote:
Message was sent to me privately... so i am posting it to the list
-
But for example, in the JPetStoreExample, in the AccountSqlMapDao, this
is
a
method:
public void insertAccount(Account account) {
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
Aren't those different update statements better off in a transaction?
And
why no different calls from the Service layer?
I'm just trying to understand the difference.
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: transactions
Date: Tue, 24 May 2005 12:45:59 -0600
It is not neccessary to call transactions on only one statement.
Transactions should be handled on the Service layer and make more
fine-grained calls to the DAO layer.
Brandon
On 5/24/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
At http://www.reumann.net/struts/ibatisLesson1/step6.do
this is an example in a ibatis/struts tutorial
public int update(String statementName, Object parameterObject)
throws
DaoException {
int result = 0;
try {
sqlMap.startTransaction();
result = sqlMap.executeUpdate(statementName, parameterObject);
sqlMap.commitTransaction();
} catch (SQLException e) {
try {
sqlMap.rollbackTransaction();
} catch (SQLException ex) {
throw new DaoException(ex.fillInStackTrace());
}
throw new DaoException(e.fillInStackTrace());
}
return result;
}
Is it necessary to have a transaction started for just 1 statement
execution?
Also, what's the better way? Doing a transaction in a Service class,
that
has multiple DAO's, or doing it in the DAO class, doing different
statements
in one method? Or is there no difference?
RE: transactions
Yes, I see. But does that mean that I should put every call to a dao that
occurs in the service in a transaction?
If this is the case:
Service Layer:
doaManager.startTransaction();
accountDao.insertAccount(account);
doaManager.commitTransaction();
finally(){doaManager.endTransaction():}
Dao Layer:
public void insertAccount(Account account)
{
update(insertAccount, account);
}
Would this startTransaction() call still be necessary?
From: Jason Hall [EMAIL PROTECTED]
Reply-To: ibatis-user-java@incubator.apache.org
To:
ibatis-user-java@incubator.apache.org,[EMAIL PROTECTED],[EMAIL PROTECTED]
Subject: RE: transactions
Date: Tue, 24 May 2005 16:00:11 -0400
if a an error occurs in any of these 3 updates below
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
a rollback will occur before the daoManager.commitTransaction().
So isn't it safe to say that these updates a wrapped in the transaction?
Also doesn't this constitute a valid insert of Account?
Example:
Service Layer:
doaManager.startTransaction();
accountDao.insertAccount(account);
doaManager.commitTransaction();
finally(){doaManager.endTransaction():}
Dao Layer:
public void insertAccount(Account account)
{
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
-Original Message-
From: Lieven De Keyzer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 3:48 PM
To: [EMAIL PROTECTED]; ibatis-user-java@incubator.apache.org;
[EMAIL PROTECTED]
Subject: Re: transactions
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org, Brandon Goodin
[EMAIL PROTECTED]
Subject: Re: transactions
Date: Tue, 24 May 2005 13:40:04 -0600
Those update statements ARE in a transaction. But you should NEVER manage
transactions inside the DAO. The transaction in this case is taken care
of
outside of the scope of this particular method (I believe in this case it
is
actually an automatic DAO transaction, so you might not find the calls to
start/commit/end).
So, what you mean is: I should make the transaction in my service layer,
and
inside this transaction call the dao method. But if I change a method in my
DAO, to have multiple statements, I would also need to change my Service
class, to place the call in a transaction?
And how does one specify those automatic transactions?
Clinton
On 5/24/05, Brandon Goodin [EMAIL PROTECTED] wrote:
Message was sent to me privately... so i am posting it to the list
-
But for example, in the JPetStoreExample, in the AccountSqlMapDao,
this
is
a
method:
public void insertAccount(Account account) {
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
Aren't those different update statements better off in a transaction?
And
why no different calls from the Service layer?
I'm just trying to understand the difference.
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: transactions
Date: Tue, 24 May 2005 12:45:59 -0600
It is not neccessary to call transactions on only one statement.
Transactions should be handled on the Service layer and make more
fine-grained calls to the DAO layer.
Brandon
On 5/24/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
At http://www.reumann.net/struts/ibatisLesson1/step6.do
this is an example in a ibatis/struts tutorial
public int update(String statementName, Object parameterObject)
throws
DaoException {
int result = 0;
try {
sqlMap.startTransaction();
result = sqlMap.executeUpdate(statementName, parameterObject);
sqlMap.commitTransaction();
} catch (SQLException e) {
try {
sqlMap.rollbackTransaction();
} catch (SQLException ex) {
throw new DaoException(ex.fillInStackTrace());
}
throw new DaoException(e.fillInStackTrace());
}
return result;
}
Is it necessary to have a transaction started for just 1 statement
execution?
Also, what's the better way? Doing a transaction in a Service
class,
that
has multiple DAO's, or doing it in the DAO class, doing different
statements
in one method? Or is there no difference?
Re: Transactions
Sorry to pick this up again, but I still have got one question.
Wouldn't it be save to always wrap the calls in the service layer to the dao
layer, in transactions? If this would be the case:
accountDao.insertAccount(account);
Dao Layer:
public void insertAccount(Account account)
{
update(insertAccount, account);
}
There seems no need to use a startTransaction in the service layer, because
only one statement is executed. But if the insertAccount method would change
to:
public void insertAccount(Account account)
{
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
I would have to alter de Service layer code. I think it's a bit weird and
violates the principles of OO. I guess I'm seeing this totally wrong?
I think we are getting in to splitting hairs here. The answer on where
to put it would have to reside in whether you will be
updating/inserting accounts from any other location and if it is a
requirement that everytime you update/insert an account that you also
update/insert a profile and a signon. There are probably a dozen other
reasons i could come up with that would influence where to put it. My
general rule on things like this is that I would push it up into the
Service layer regardless because insertAccount, insertProfile and
insertSignon are fine-grained calls that possible could be used
outside of this block. But, like i said above... that judgment may
change based on the business rules. But, truly, i don't think there
is an easy this way is right approach.
Brandon
On 5/24/05, Jason Hall [EMAIL PROTECTED] wrote:
if a an error occurs in any of these 3 updates below
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
a rollback will occur before the daoManager.commitTransaction().
So isn't it safe to say that these updates a wrapped in the transaction?
Also doesn't this constitute a valid insert of Account?
Example:
Service Layer:
doaManager.startTransaction();
accountDao.insertAccount(account);
doaManager.commitTransaction();
finally(){doaManager.endTransaction():}
Dao Layer:
public void insertAccount(Account account)
{
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
-Original Message-
From: Lieven De Keyzer [mailto:[EMAIL PROTECTED]
Sent: Tuesday, May 24, 2005 3:48 PM
To: [EMAIL PROTECTED]; ibatis-user-java@incubator.apache.org;
[EMAIL PROTECTED]
Subject: Re: transactions
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org, Brandon Goodin
[EMAIL PROTECTED]
Subject: Re: transactions
Date: Tue, 24 May 2005 13:40:04 -0600
Those update statements ARE in a transaction. But you should NEVER manage
transactions inside the DAO. The transaction in this case is taken care
of
outside of the scope of this particular method (I believe in this case it
is
actually an automatic Ddo you have AO transaction, so you might not find
the calls to
start/commit/end).
So, what you mean is: I should make the transaction in my service layer,
and
inside this transaction call the dao method. But if I change a method in my
DAO, to have multiple statements, I would also need to change my Service
class, to place the call in a transaction?
And how does one specify those automatic transactions?
Clinton
On 5/24/05, Brandon Goodin [EMAIL PROTECTED] wrote:
Message was sent to me privately... so i am posting it to the list
-
But for example, in the JPetStoreExample, in the AccountSqlMapDao,
this
is
a
method:
public void insertAccount(Account account) {
update(insertAccount, account);
update(insertProfile, account);
update(insertSignon, account);
}
Aren't those different update statements better off in a transaction?
And
why no different calls from the Service layer?
I'm just trying to understand the difference.
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: transactions
Date: Tue, 24 May 2005 12:45:59 -0600
It is not neccessary to call transactions on only one statement.
Transactions should be handled on the Service layer and make more
fine-grained calls to the DAO layer.
Brandon
On 5/24/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
At http://www.reumann.net/struts/ibatisLesson1/step6.do
this is an example in a ibatis/struts tutorial
public int update(String statementName, Object parameterObject)
throws
DaoException {
int result = 0;
try {
sqlMap.startTransaction();
result = sqlMap.executeUpdate(statementName, parameterObject);
sqlMap.commitTransaction();
} catch (SQLException e) {
try {
sqlMap.rollbackTransaction();
} catch (SQLException ex) {
throw new DaoException(ex.fillInStackTrace());
}
throw new DaoException(e.fillInStackTrace());
}
return
Re: complex inserts?
From: Larry Meadors [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: complex inserts?
Date: Mon, 23 May 2005 21:50:01 -0600
That all sounds like logic for your DAO or business layer.
SQL maps are more fine-grained that that.
Larry
On 5/23/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
In fact, it's even complexer than this, because when a certain
notification
is given as parameter and it is not present yet, is should be inserted,
when
it is present, nothing should happen, and when it's not given as
parameter,
it should be deleted.
Hmm, I see. But these notificationWays belong to a Bookmark I think. So I
should make these kind of test in the DAO layer. And make separate insert
etc. statements for the bookmark table and for the notifications table?
But is it ok, to do something like:
updateBookmark(Bookmark){
update(updateBookmark, bookmark);
List notif = queryForList(getNotificationsByBookmark, bookmark);
//perform various tests to see which notifications are already present
and wich are not.
//insert some notifications, update some and delete some
}
RE: [HELP] I can't not type sign in my sqlmap xml file
use the entity reference lt; instead From: Pham Anh Tuan [EMAIL PROTECTED] Reply-To: ibatis-user-java@incubator.apache.org To: ibatis-user-java@incubator.apache.org Subject: [HELP] I can't not type sign in my sqlmap xml file Date: Thu, 19 May 2005 16:06:08 +0700 Hi, I can't not type sign in sql definition xml file, I don't know why, plz help me solve this problem :( select id=getNOFBidding resultClass=int parameterClass=string select COUNT(distinct ITEMID) from SALE where SALESTATUS = 0 and MAXPRICE = 1 and TO_DAYS(NOW()) - TO_DAYS(SALEDATE) = 15 and TO_DAYS(NOW()) - TO_DAYS(SALEDATE) 0 and BUYERUSERID = #value# /select report error: The content of elements must consist of well-formed character data or markup Thanks for reading Anh Tuan
Re: [OT] JPetStore - BaseBean / BeanAction
Yes, I realize this, but a form can only have one action specified I
believe?
So this method would need to have a case where other methods can be called?
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: [OT] JPetStore - BaseBean / BeanAction
Date: Thu, 12 May 2005 21:56:55 -0600
It should be noted that JPetStore also performs multiple actions per
form.
The difference is that with BeanAction, you must call a different URL for
each action. (I quote action, as there is obviously only one actual
Action
class...).
Clinton
On 5/12/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: [OT] JPetStore - BaseBean / BeanAction
Date: Thu, 12 May 2005 19:01:02 -0600
i'm not sure about your formAction semantic. You should name it
something meaningful like removeFoo. The method names should be
named after the actions that are taking place.
Yes, I should have given my real problem instead of this one. But that
would
mean my action would be called: folderActions. And the methods foo and
bar
would be: remove and edit.
But, yes you would follow the same semantic. You need to realize that
JPetstore is NOT
standard struts practice. It is a way to use struts in a more modern
manner (i.e. Action has properties on it rather than sepearate in an
ActionForm.).
And I like this modern way better than the old one. :)
Otherwise, it sounds like you have the idea down fairly well.
Brandon
On 5/12/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
I took the lastest JPetStore as a starting point for my application.
The problem I have now: I want to have multiple actions in one form.
I
have
a set of objects belonging to a user and this are displayed together
with a
checkbox for each object. I want the users to be able to check a few
boxes
and let them choose to delete those, or edit them all at once,
etc...
Normall I think one should implement a class that inherits from the
DispatchAction Class.
I guess using the BaseBean and BeanAction class, this should even be
simpler. Should I use the same tactic as the DispatchAction class
uses
?
Something like:
public Class TreeLevel extends BaseBean {
private String method;
public String formAction {
if (method == foo) {
return foo(); }
else { return bar(); }
}
private String foo() {
//
}
private String bar() {
}
}
And then in my jsp page:
html:form action=/formAction
html:submit property=method value=foo /
html:submit property=method value=bar /
/html:form
[OT] JPetStore - BaseBean / BeanAction
I took the lastest JPetStore as a starting point for my application.
The problem I have now: I want to have multiple actions in one form. I have
a set of objects belonging to a user and this are displayed together with a
checkbox for each object. I want the users to be able to check a few boxes
and let them choose to delete those, or edit them all at once, etc...
Normall I think one should implement a class that inherits from the
DispatchAction Class.
I guess using the BaseBean and BeanAction class, this should even be
simpler. Should I use the same tactic as the DispatchAction class uses ?
Something like:
public Class TreeLevel extends BaseBean {
private String method;
public String formAction {
if (method == foo) {
return foo(); }
else { return bar(); }
}
private String foo() {
//
}
private String bar() {
}
}
And then in my jsp page:
html:form action=/formAction
html:submit property=method value=foo /
html:submit property=method value=bar /
/html:form
Re: [OT] JPetStore - BaseBean / BeanAction
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: [OT] JPetStore - BaseBean / BeanAction
Date: Thu, 12 May 2005 19:01:02 -0600
i'm not sure about your formAction semantic. You should name it
something meaningful like removeFoo. The method names should be
named after the actions that are taking place.
Yes, I should have given my real problem instead of this one. But that would
mean my action would be called: folderActions. And the methods foo and bar
would be: remove and edit.
But, yes you would follow the same semantic. You need to realize that
JPetstore is NOT
standard struts practice. It is a way to use struts in a more modern
manner (i.e. Action has properties on it rather than sepearate in an
ActionForm.).
And I like this modern way better than the old one. :)
Otherwise, it sounds like you have the idea down fairly well.
Brandon
On 5/12/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
I took the lastest JPetStore as a starting point for my application.
The problem I have now: I want to have multiple actions in one form. I
have
a set of objects belonging to a user and this are displayed together
with a
checkbox for each object. I want the users to be able to check a few
boxes
and let them choose to delete those, or edit them all at once, etc...
Normall I think one should implement a class that inherits from the
DispatchAction Class.
I guess using the BaseBean and BeanAction class, this should even be
simpler. Should I use the same tactic as the DispatchAction class uses ?
Something like:
public Class TreeLevel extends BaseBean {
private String method;
public String formAction {
if (method == foo) {
return foo(); }
else { return bar(); }
}
private String foo() {
//
}
private String bar() {
}
}
And then in my jsp page:
html:form action=/formAction
html:submit property=method value=foo /
html:submit property=method value=bar /
/html:form
Re: SQLException when deleting
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: SQLException when deleting
Date: Sun, 8 May 2005 21:45:01 -0600
Oddthe DAO template doesn't throw an exception...
public int delete(String id, Object parameterObject) {
Maybe you're using an old version of the framework?
Cheers,
Clinton
On 5/8/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
This is a snapshot of my AccountSqlMapDao, following the concepts of the
latest JPetStore.
public void insertAccount(Account account) {
insert(insertAccount, account);
}
public void updateAccount(Account account) {
update(updateAccount, account);
}
public void deleteAccount(Account account) {
delete(deleteAccount, account);
}
I get an error however in deleteAccount:
unreported exception java.sql.SQLException; must be caught or declared
to
be
thrown
[javac] delete(deleteAccount, account);
Why do I need to catch the exception for the delete statement, but not
for
the insert or update method?
Re: SQLException when deleting
This indeed solved my problem. Thanks a lot!
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Lieven De Keyzer [EMAIL PROTECTED]
Subject: Re: SQLException when deleting
Date: Mon, 9 May 2005 08:35:28 -0600
Try getting v2.0.9b. JPetStore doesn't necessarily come with the latest
iBATIS JAR. They are separate development paths.
Cheers,
Clinto
On 5/9/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
From: Clinton Begin [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: SQLException when deleting
Date: Sun, 8 May 2005 21:45:01 -0600
Oddthe DAO template doesn't throw an exception...
public int delete(String id, Object parameterObject) {
Maybe you're using an old version of the framework?
I'm using the same jar files for the DAO and SqlMaps frameworks as used
in
the latest version of the JPetStore example.
Anyway, here is the complete file:
package com.vub.bookmarked.persistence.sqlmapdao;
import com.ibatis.dao.client.DaoManager;
import com.vub.bookmarked.domain.Account;
import com.vub.bookmarked.persistence.iface.AccountDao;
public class AccountSqlMapDao extends BaseSqlMapDao implements
AccountDao
{
public AccountSqlMapDao(DaoManager daoManager) {
super(daoManager);
}
public Account getAccount(String username) {
return (Account) queryForObject(getAccountByUsername, username);
}
public Account getAccount(String username, String password) {
Account account = new Account();
account.setUsername(username);
account.setPassword(password);
return (Account) queryForObject(getAccountByUsernameAndPassword,
account);
}
public void insertAccount(Account account) {
insert(insertAccount, account);
}
public void updateAccount(Account account) {
update(updateAccount, account);
}
public void deleteAccount(Account account) {
delete(deleteAccount, account);
}
}
Cheers,
Clinton
On 5/8/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
This is a snapshot of my AccountSqlMapDao, following the concepts of
the
latest JPetStore.
public void insertAccount(Account account) {
insert(insertAccount, account);
}
public void updateAccount(Account account) {
update(updateAccount, account);
}
public void deleteAccount(Account account) {
delete(deleteAccount, account);
}
I get an error however in deleteAccount:
unreported exception java.sql.SQLException; must be caught or
declared
to
be
thrown
[javac] delete(deleteAccount, account);
Why do I need to catch the exception for the delete statement, but
not
for
the insert or update method?
SQLException when deleting
This is a snapshot of my AccountSqlMapDao, following the concepts of the
latest JPetStore.
public void insertAccount(Account account) {
insert(insertAccount, account);
}
public void updateAccount(Account account) {
update(updateAccount, account);
}
public void deleteAccount(Account account) {
delete(deleteAccount, account);
}
I get an error however in deleteAccount:
unreported exception java.sql.SQLException; must be caught or declared to be
thrown
[javac] delete(deleteAccount, account);
Why do I need to catch the exception for the delete statement, but not for
the insert or update method?
Re: Re: struts vs ibatis - Integer type
The only way to make that clean is to push the translation effort
into your ActionForm and nest your real beans in the ActionForm. you
would then have a String value that you convert and set into your
nested bean. The other option is to write a different BeanUtils
Converter implementation for numerics and register it
(http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConvertUtils.html#register(org.apache.commons.beanutils.Converter,%20java.lang.Class).
I like this second approach because I presume that in this case, all INTEGER
columns will be set to NULL if no value is provided. I just don't see why an
empty INTEGER column should be 0.
But how would I approach this problem? First rewrite the Jakarata commons
converter, and then recompile the iBatis classes with these commons classes?
I would personally avoid cluttering up your domain bean with faux
setters and getters.
Brandon
On 5/2/05, Darek Dober [EMAIL PROTECTED] wrote:
Hi, I hava a table 'users' with column dept_id (id of department in
departments
table) This column is optional. That means the operator doesn't have to
assign
inserted user to any department. If I have bean: public class UserBean
{ Integer departmentId; } struts will make automatic
conversion of type. So departmentId will be set
to 0, if I don't set any of department. That's a cheat, because, I don't
want to to have a department with id equals to 0, it should be NULL. On
the other hand, when I implement departmentId as String, struts act
correctly. But while inserting record to the database, I get an error sth
like this: database column dept_id is type of bigint, inserted value is
type of
varchar.
I have the solution: departmentId is type of String, but for ibatis I
have
the other metod getDepartmentIdAsInteger which return Integer or null if
value is empty. It works, but i don't like this. Is there any cleaner
solution for this. I looked into jpetstore, but there
were columns of type varchar. Rest of them was mendatory. I cannot use
columns of type varchar as foreign keys. Usage: VALUES(
#departmentId:INTEGER#,
doesn't help if departmentId is String Any ideas? Darek
Re: Re: struts vs ibatis - Integer type
From: Brandon Goodin [EMAIL PROTECTED]
Reply-To: Brandon Goodin [EMAIL PROTECTED]
To: ibatis-user-java@incubator.apache.org
Subject: Re: Re: struts vs ibatis - Integer type
Date: Fri, 6 May 2005 10:06:36 -0600
Your problem is not ibatis. Your problem is how BeanUtils within
Struts translates an empty request parameter into an Integer property
on your bean. I would handle this issue on the Struts layer. You can
handle it either in your action form with a setter that receives a
string and sets the value into your bean or you can write a custom
Converter for BeanUtils.
But as far is I see, when a Bean is constructed, an int property will always
be 0, when not specified. So when I perform an insert through iBatis
SQLmaps, this beanproperty will always be an integer? Where exactly are the
commons classes needed and created ?
Perhaps I'm not really understanding the purpose of the ConvertUtils and
BeanUtils.
It's just that this is my first real project in Java and I find the apidocs
of this kind of projects a little bit overwhelming. So a bit OT then, could
you point me to a good resource about this topic?
I recommend that you post this question to
the Struts list.
Brandon
On 5/6/05, Lieven De Keyzer [EMAIL PROTECTED] wrote:
The only way to make that clean is to push the translation effort
into your ActionForm and nest your real beans in the ActionForm. you
would then have a String value that you convert and set into your
nested bean. The other option is to write a different BeanUtils
Converter implementation for numerics and register it
(http://jakarta.apache.org/commons/beanutils/api/org/apache/commons/beanutils/ConvertUtils.html#register(org.apache.commons.beanutils.Converter,%20java.lang.Class).
I like this second approach because I presume that in this case, all
INTEGER
columns will be set to NULL if no value is provided. I just don't see
why an
empty INTEGER column should be 0.
But how would I approach this problem? First rewrite the Jakarata
commons
converter, and then recompile the iBatis classes with these commons
classes?
I would personally avoid cluttering up your domain bean with faux
setters and getters.
Brandon
On 5/2/05, Darek Dober [EMAIL PROTECTED] wrote:
Hi, I hava a table 'users' with column dept_id (id of department
in
departments
table) This column is optional. That means the operator doesn't have
to
assign
inserted user to any department. If I have bean: public class
UserBean
{ Integer departmentId; } struts will make automatic
conversion of type. So departmentId will be set
to 0, if I don't set any of department. That's a cheat, because, I
don't
want to to have a department with id equals to 0, it should be NULL.
On
the other hand, when I implement departmentId as String, struts act
correctly. But while inserting record to the database, I get an error
sth
like this: database column dept_id is type of bigint, inserted value
is
type of
varchar.
I have the solution: departmentId is type of String, but for ibatis
I
have
the other metod getDepartmentIdAsInteger which return Integer or null
if
value is empty. It works, but i don't like this. Is there any
cleaner
solution for this. I looked into jpetstore, but there
were columns of type varchar. Rest of them was mendatory. I cannot use
columns of type varchar as foreign keys. Usage: VALUES(
#departmentId:INTEGER#,
doesn't help if departmentId is String Any ideas? Darek
Re: Re: struts vs ibatis - Integer type
From: Larry Meadors [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: ibatis-user-java@incubator.apache.org Subject: Re: Re: struts vs ibatis - Integer type Date: Fri, 6 May 2005 12:31:35 -0600 On 5/6/05, Lieven De Keyzer [EMAIL PROTECTED] wrote: But as far is I see, when a Bean is constructed, an int property will always be 0, when not specified. So when I perform an insert through iBatis Yes, int properties will always have a non-null value...if you need nullable properties, you must use the Object wrappers instead (Integer instead of int, etc...) Ah, I see. SQLmaps, this beanproperty will always be an integer? Where exactly are the commons classes needed and created ? Perhaps I'm not really understanding the purpose of the ConvertUtils and BeanUtils. ConvertUtils and BeanUtils are not used in any way in iBATIS. Period. I wasn't questioning your knowledge about the the iBatis framework. :) I was just wondering about these classes because they were mentioned in an earlier mail. Larry
selectKey and MySql problem
I've searched the archive for this issue, but still couldn't solve it.
I'm working on a webbased application using Struts 1.2.4, iBatis SQL Maps
2.0 and iBatis DAO Framework. I also try to stick close to the concept of
JPetStore 4.0.5.
The problem I encounter is with the selectKey stanza.
These are in Folder.xml
typeAlias alias=folder type=com.vub.bookmarked.domain.Folder/
resultMap id=folderResult class=folder
result property=folderId column=folder_id/
result property=parentId column=parent_id/
result property=owner column=owner/
result property=foldername column=foldername/
/resultMap
insert id=insertFolder parameterClass=folder
INSERT INTO folder (parent_id, owner, foldername)
VALUES (#parentId#, #owner#, #foldername#)
selectKey resultClass=int keyProperty=folderId
SELECT LAST_INSERT_ID() AS folderId
/selectKey
/insert
I catch this key in FolderSqlMapDao.java:
public int insertFolder(Folder folder) {
int key = update(insertFolder, folder);
return key;
}
But this key always seems to be the first inserted element, so 1 . For all
the folders that get inserted afterwards, selectKey always returns this 1.
