When you say "neither worked properly", what do you mean? Did you
get an exception? Or did you just get unexpected results?
Did you override both equals() and hashCode() for the complex property
type? As per the standard? Here's a description of how to
override them properly:
http://www.geoci
That code is very incomplete. It's hard to see what you're trying to do.
Why are you accessing the DataSource directly? How are you even doing that?
In any case, why don't you just use the JdbcDaoTemplate and call
getConnection(). Then you never have to worry about opening and
closing connect
Thanks for sharing this Brian.
Keep us posted on anything you learn about this. Even though it's
the driver's problem, we'd be interested if there was anything that we
can do with iBATIS to improve it.
Clinton
On 5/23/05, Barnett, Brian W. <[EMAIL PROTECTED]> wrote:
I
decided to attempt
It certainly would be safer to always declare a transaction in your
Service layer. Any time i perform an update, delete or insert i wrap
it in a transaction, even if i know the underlying only makes one
update/insert/delete. I think your conclusion is very sound.
Brandon
On 5/24/05, Lieven De Key
> Seeing as I need this capability, and someone else has
> resorted to using temp files to accomplish the same
> thing, it sounds like it would be a useful feature to
> have.
Actually, I like the temp file way of doing this, I wouldn't say I
resorted to it. It came as the natural solution. It doesn
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("i
"freemarker and velocity macros can create the same tags"
The point is simply this... mixing semantics looks like hell. When you
start mixing xml with velocity for no good reason your < becomes a
minor blip on the radar of messy. The other reason is that you
introduce the FULL ability of velocity
Clinton Begin wrote:
I agree with Brandon. There are definite improvements we need to make
to iBATIS dynamic SQL, but that does NOT include building a full
templating language. The power of iBATIS dynamic SQL is the fact that
it is VERY specific to SQL. Using iBATIS dynamic SQL, you can re
Thanks Brandon,
I beleive we are saying the same thing. The only difference, as you mentioned,
is where
based on the business rules to put your crud statements. Maybe the petstore
example a user may need
direct access to profile so yah this is needed at the service layer, however i
have situat
If you do not call start transaction then each update call in the dao
class will be in it's own transaction. This means that you would have
incomplete data if any of them failed for any reason. If you wrap the
call to the accountDao.insertAccount(account); with the transaction...
then all of the up
Correct me if I'm wrong, my understanding is that the call to startTransactions
in the service layer
automatically is aware of the methods to all called dao classes. If the the
startTransaction is not called at all
then those 3 updates in the dao layer are not in the transaction. Therefore you
if you want the internal udpates to be in a transaction... yes.
Otherwise they will each execute in their own transaction apart from
each other.
Brandon
On 5/24/05, Lieven De Keyzer <[EMAIL PROTECTED]> wrote:
> Yes, I see. But does that mean that I should put every call to a dao that
> occurs in
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.
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():}
D
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 transact
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
transact
In this case i would have pulled the individual calls out to the
service layer and wrapped them in a transaction. I have some rare
cases where i have needed to place more complex code in my dao. In
those cases i still wrap the single call to my method in a transaction
on the service layer.
Brandon
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 t
I agree with Brandon. There are definite improvements we need to
make to iBATIS dynamic SQL, but that does NOT include building a full
templating language. The power of iBATIS dynamic SQL is the fact
that it is VERY specific to SQL. Using iBATIS dynamic SQL, you
can reduce the amount of code to
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("inser
As great as that tutorial was for iBATIS 1.x, it holds little value for the 2.0 framework.
For one, the new exception handling paradigm is completely different.
Please see the Tutorial available at www.ibatis.com and JPetStore 4.
Cheers,
ClintonOn 5/24/05, Lieven De Keyzer <[EMAIL PROTECTED]> w
H...this might require some investigation. Here's how you can help:
Investigate how OSCache allows properties to be specified
programmatically at runtime. Once that's been figured out, we
might be able to provide some mechanism whereby you can pass OSCache
properties into the cache model d
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
> thi
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(statem
Can some please post a sample code using the javax.sql.DataSource;
to get connection and to also close the connection in the try final….
Something like this…
Thanks
import javax.sql.DataSource;
DataSource dataSource ;
try {
connection = dataSource.getConn
At 01:14 PM 5/24/2005, Brandon Goodin wrote:
You can easily create an account. I'd prefer that you enter it in so
that we can ask you questions as we begin to review it.
On another project that I work on that uses Jira anyone reporting an issue
is asked to create an account and create the issu
You can easily create an account. I'd prefer that you enter it in so
that we can ask you questions as we begin to review it.
Brandon
On 5/24/05, Rob Butler <[EMAIL PROTECTED]> wrote:
> Isn't that what I just did? :)
>
> I don't have a Jira account for iBatis, so could
> someone add this for me?
Hi all!
I would ask anybody if you know the way to configurate OSCACHE while I
inizialized SQLMAPCLIENT.
I need to understand the way to setting property that fixes dynamic
cache localization on the disk: now this property is only configurable
by OSCACHE.PROPERTIES configuration file, settled
Isn't that what I just did? :)
I don't have a Jira account for iBatis, so could
someone add this for me?
Thanks
Rob
--- Brandon Goodin <[EMAIL PROTECTED]> wrote:
> Oh duh. haha. sorry. Read it quick. Should have
> taken a few more seconds.
>
> Follow the second temp file suggestion for now. It
Oh duh. haha. sorry. Read it quick. Should have taken a few more seconds.
Follow the second temp file suggestion for now. It is not a terribly
difficult way to solve this at all. Please put a feature request in
for this. I'm not sure we will add this feature. But, at least get it
in the que so tha
Because, as I said below, SqlMapClientBuilder requires
the SqlMapConfig file. So if I use StringReader to
pass in the SqlMapConfig file, that works fine. But
the SqlMapConfig file must then reference the SqlMap
file, and this file must be loaded either as a
resource from the classpath, or as a UR
"I guess it's always been a bit of a merry go round."
This may be true in cases where folks allow thing to get out of hand.
IBatis has maintained a very focused approach. There has not been a
real need to introduce a full blown templating language. Cuz if your
requirements get that complex... do i
Brandon Goodin wrote:
I don't plan on promoting any templating languages. It offloads the
burden to another layer. The dyanmic conditionals would get out of
hand. At that point it would be far easier to handle things in java.
The heirarchal nature of xml is of great importance to dynamic sql.
So,
33 matches
Mail list logo
