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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> > 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 <[EMAIL PROTECTED]> 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 > > > > > >
