Have you looked at iBATOR for generating all that conditional CRUD stuff? Might be worth your time.
On 5/13/08 3:11 PM, "Josh Joy" <[EMAIL PROTECTED]> 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 <[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 >>>> >>> >>
