ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh Joy" <joshjd...@gmail.com>
Subject Re: Dynamic queries w/o using <dynamic> tags in sql?
Date Tue, 13 May 2008 22:11:14 GMT
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
> > > > > >  >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> >
> >
>

Mime
View raw message