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 21:11:31 GMT
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