On Tue, May 13, 2008 at 4:11 PM, Josh Joy <joshjdevl@gmail.com> wrote:

I guess I'll just look into this further then...I think I have a decent enough understanding of concurrency...I'm just of the mood to let the database handle the concurrency issues for me as much as possible rather bringing it to the java object side...

Going back to the original question...it seems that the answer is no...there is no other way to dynamically generate sql for updates for ibatis other than specifying the <dynamic> tag in sqll

(also it's not a business exception if the business allows different people to update only certain fields....)

Thanks for info,
Josh

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

Josh...

I think you really need to look into this further, as you have a
fundamental misunderstanding of concurrency issues and databases.

* Separating the updates at the column level will NOT solve any
concurrency problem
* Concurrency issues are solved using either an optimistic or
pessimistic locking model at the row level

I recommend optimistic for most systems.

Table Josh
id
name
weburl

timestamp

update josh set ..., timestamp = now() where id = ? and timestamp = ?

If the timestamps don't match, it's not simply a technical problem of
reloading the object. You have to tell the user what happened... it's
a business exception. What if the user would have changed the name
differently if the URL was different or vice versa?

Pessimistic locking would lock the record so that it could not be
updated (and in some cases not even read) until it's unlocked. It's
rare to need this type of locking in most business applications.

This is a pretty core concept in database programming that you should
understand before using iBATIS, Hibernate or even just JDBC. One book
I can recommend is Java Transaction Processing (Mark Little), page 11
- 12.

Any other book recommendations from anyone else?

Cheers,
Clinton

On Tue, May 13, 2008 at 3:36 PM, Josh Joy <joshjdevl@gmail.com> wrote:
>
> 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
> > > > > >
> > > > >
> > > >
> > >
> > >
> >
>
>