ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nathan Maves" <nathan.ma...@gmail.com>
Subject Re: Dynamic queries w/o using <dynamic> tags in sql?
Date Mon, 19 May 2008 02:34:11 GMT
Josh,

One little point...  With your approach using dynamic tags you would never
be able to set a column to null, which is a very real business case.

Nathan

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
>> > > > > >  >
>> > > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>> >
>> >
>>
>
>

Mime
View raw message