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 Mon, 19 May 2008 03:07:20 GMT
I'm guess I'm really not sure why this thread is so long...

There exists a dynamic tag already which can be used in the xml? Yes...? No?

All I was looking for was a way to abstract it out...which can't be
done...thread closed. Thanks...

On Sun, May 18, 2008 at 9:34 PM, Nathan Maves <nathan.maves@gmail.com>
wrote:

> 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