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