ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris O'Connell" <oconn...@gorillachicago.com>
Subject RE: Dynamic queries w/o using <dynamic> tags in sql?
Date Tue, 13 May 2008 21:58:29 GMT
I don't think iBatis does this for you.  You have to implement either a
pessimistic locking solution (select for update) or use optimistic locking.
Add a version or timestamp to the table.  When you update the record, do
something like this

 

Update josh set name = #name#, weburl = #weburl#, version = version + 1
where id = #id# and version = #version#

 

If you do this, you have to track the number of records updated.  If the
number updated = 1, all is good.  If the number updated is zero, that means
someone else updated the record underneath you.

 

For what it is worth, this problem is not specific to iBatis.  If you use
Hibernate, you still have to deal with these types of concurrency issues and
you still have to deal with a failure if someone updates the record on you.
Or, you can choose to ignore it if it does happen (but once again, you are
still making the same choice whether you use iBatis or Hibernate).  Note,
this problem doesn't exist only if someone wants to update the "weburl"
while you are updating the "name".  You also have the problem of someone
else updating the "name" while you are updating the "name".

 

Chris

 

From: josh.joy.123@gmail.com [mailto:josh.joy.123@gmail.com] On Behalf Of
Josh Joy
Sent: Tuesday, May 13, 2008 4:37 PM
To: user-java@ibatis.apache.org
Subject: Re: Dynamic queries w/o using <dynamic> tags in sql?

 


Table Josh
  id
  name
  weburl

If one user wants to update the name, and another user wants to update the
weburl...how to avoid concurrency issues if I have to do a reload of the
entire object? 
Please let me know how to configure Ibatis to handle state concurrency
issues if I have to fetch the entire object...


Thanks,
Josh



On Tue, May 13, 2008 at 4:25 PM, Clinton Begin <clinton.begin@gmail.com>
wrote:

So is it completely out of the question to just load up the whole
object and save the whole object?  Why do you ever need any
conditionals or partial updates at all?  The only reason is
performance (and even that really depends on the details).

I don't see the problem here... :-/

Clinton


On Tue, May 13, 2008 at 3:11 PM, Josh Joy <joshjdevl@gmail.com> wrote:
> Thanks Clinton for your reply.
>
> Just to clarify...I'm not looking for any performance optimizations...when
I
> say best practices I'm referring to dynamically choosing which fields to
> update...
>
> it comes down strictly to simplicity and readability...I don't see a
reason
> to fetch the latest entries for a row just so I can do an update (and how
> can I possibly guarantee it's the latest entry) nor do I see a reason to
> write multiple update statements or an if statement laden sql for all the
> possible update situations that can occur...
>
> I'll start poking around the api to see if I can wrap something up for my
> needs for now I guess... (unless anyone has any other suggestions, code
> snippets, or patches to share...)
>
> Thanks,
> Josh
>
>
>
>  On Tue, May 13, 2008 at 3:53 PM, Clinton Begin <clinton.begin@gmail.com>
> wrote:
> > Wow, I managed to lay down 3 or 4 run-on sentences in a row there...
> > Sorry Mr. McMillan...
> >
> >
> >
> >
> > On Tue, May 13, 2008 at 2:52 PM, Clinton Begin <clinton.begin@gmail.com>
> wrote:
> > > Josh,
> > >
> > >  Some people do care enough about this to do something about it.  And
> > >  yes, Hibernate is able to support it easily, because it has dirty
> > >  checking, object identity and generates the SQL for the update.
> > >
> > >  iBATIS is a SQL based framework.  It does not generate the SQL for
> > >  you, nor does it track dirty state or object identity etc.  It's
> > >  pretty safe to say that iBATIS will never support this in any way,
> > >  even if we do add SQL generation for convenience, the lack of dirty
> > >  checking etc. will keep this from ever being a practical possibility.
> > >
> > >  I recommend looking into your particular situation.  I'd bet that it
> > >  doesn't matter as much as you think it does, or if it does matter in
> > >  one or two cases -- handle those cases as a performance tweak.
> > >
> > >  To answer your question about best practices, I'm not sure anyone has
> > >  ever told me that this was a fully agreed upon best practice, but I
do
> > >  know a lot of people that think that premature performance
> > >  optimization is a practice to avoid...
> > >
> > >  Cheers,
> > >  Clinton
> > >
> > >
> > >
> > >  On Tue, May 13, 2008 at 2:37 PM, Josh Joy <joshjdevl@gmail.com>
wrote:
> > >  >
> > >  >
> > >  > Hi,
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > If I have an sql like the following...
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > <select id="updateEmployees" >
> > >  >
> > >  >      Update  emp
> > >  >
> > >  >       <dynamic prepend="WHERE">
> > >  >
> > >  >               set
> > >  >
> > >  >
> > >  >             <isNotEmpty prepend="AND" property="id">
> > >  >
> > >  >                   empno=#id#
> > >  >
> > >  >             </isNotEmpty>
> > >  >
> > >  >             <isNotEmpty prepend="OR" property="name">
> > >  >
> > >  >                   ename=#name#
> > >  >
> > >  >             </isNotEmpty>
> > >  >
> > >  >       </dynamic>
> > >  >
> > >  > </select>
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > Is there a way to instruct Ibatis to ignore nulls without having to
> actually
> > >  > use a dynamic tag? I would just like to set my bean entity with the
> > >  > properties that I want updated, and leave null the ones I want to
> ignore...
> > >  >
> > >  > I know in Hibernate there is a way to do this, is there an
equivalent
> in
> > >  > Ibatis? It seems like a lot of xml code to write for all my
> updates...
> > >  >
> > >  > Is this not a best practice not to have dynamic updates, because
I'm
> unsure
> > >  > why I would have to explicitly set this in the XML? As far as I
know,
> SQL
> > >  > updates (unless using a specific database vendor call) are on a per
> table
> > >  > basis. Is it not recommended to have an entity and not always have
to
> update
> > >  > all the fields? If I wanted to modify the Ibatis API for my own
needs
> for
> > >  > the updates, where would someone recommend I start?
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > Thanks,
> > >  >
> > >  > Josh
> > >  >
> > >
> >
>
>

 

No virus found in this incoming message.
Checked by AVG.
Version: 8.0.100 / Virus Database: 269.23.16/1430 - Release Date: 5/13/2008
7:31 AM


Mime
View raw message