RE: Reactor For CF Update single value

[Doug Hughes]

I agree with you Jared.    I don’t think I’m going to implement individual field saves.   Doug   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer Sent: Thursday, February 09, 2006 5:07 PM To: reactor@doughughes.net Subject: Re: Reactor For CF Update single value   This is a challenging idea for me... not because it's hard to understand but because   <cfset MyObj.save()>   seems like it should behave one way, that is, to persist ITSELF, not it's random pieces and parts, to the database.   On the other hand,   <cfquery yadda="hrrmph">             update MyTable                         set SendMeJunkmail = 1             where userId = 'insane' </cfquery>   seems OK even if there are 30 other columns in MyTable. Why this seeming contradiction?   I suppose because MyObj.save(), semantically speaking, saves the RECORD, and breaking with that convention. Oddly enough, though, MyObj.save(argumentCollection=args) where args are key-value pairs, by name, and save() calls the setters for each key feels much better.   I guess the thing is this: The application shouldn't care how the save() function works. It shouldn't care if save() saves one field or 50... it's none of the application's business to be telling the persistence library how to do it's job. It only cares that the data gets saved. All this null/non-null stuff sounds like a lot of busy work for no real gain and a big door for strange things to happen, like "NULL" to end up in my varchar fields an a lot of extra value-checking overhead for the application.   If the save() function saves the whole record, it's behavior is consistent, and if you call load(id) before you call save() then you know that the data that's saved to the DB is saved in it's original state (other than what setters you may have called). Checking for altered state is a huge PITA and can incur heavy overhead when a simple "write the data I contain" is not only sufficient, but far safer in the long run. Like you said, updating/altering data is risky, so why make it this much more complicated?   The more I think about it, the more I think it doesn't matter if I'd update a single column with a discrete cfquery... I want my ORM behaviors stable and consistent, and save() should write the whole record as a matter of course. The Object is the Record. Save the Record!   Laterz!   ------------------------------------------------ Jared C. Rypka-Hauer Continuum Media Group LLC http://www.web-relevant.com Member, Team Macromedia - ColdFusion   "That which does not kill me makes me stranger." - Yonah Schmeidler   On Feb 9, 2006, at 3:43 PM, Chris Terrebonne wrote: Looks like I picked a bad time to lose my internet connection…   Although I respect the concept, I just can’t agree with updating an entire row for the sake of one value.  That feels like more of an “acceptable flaw”, than a loss of granularity due to OO.   The granularity can and should exist, as long as it is properly encapsulated.  Also, when it comes to data integrity, something doesn’t feel right about modifying data purely for simplicity’s sake.  Although most don’t allow this to be problematic, the simple act of updating data is far more error-prone than not modifying it in the first place. If a value doesn’t have to be changed, it shouldn’t be.    In an effort to maintain the granularity while also conforming to DRY, maybe we can take a different approach.  Rather than implement partial updates via field lists, maybe it can be done based on the record object.  When the record object is created, the values are defaulted to 0, “”, etc.  If we were to instead default those values to nulls ( see: http://www.franciswscott.com/blog/1/2005/06/Faking-a-null-value.cfm ), we could then modify the update to only change values that were not “null”.  This allows for partial updates and does not require the project code to change at all.   project = project.load(projectId=projectId) project.makeEventBean(project) project.save() When settingOne and settingTwo are set to non-null in the project record, the save() method would then only update those fields.   Thoughts?   Thanks, Chris From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Bill Rawlinson Sent: Thursday, February 09, 2006 2:28 PM To: reactor@doughughes.net Subject: Re: Reactor For CF Update single value   what you say makes sense Joe.  I honestly wasn't thinking of it purely in the scope of a bean utility specifically; partly becuase I haven't really had much opportunity to focus on just using a framework that handles all this stuff for me. I was thinking along the lines of after the quick toggle post: project.init(projectid=attributes.projectid, togglesetting=attributes.togglevalue); project.save("settingOne"); since I already have the projectID and the setting to save at the client side when I post the request I wouldn't have planned on reading the project data again (at least not at that point in the process perhaps). However, as I type this I think - what the heck, most likely with the example I gave, I'm going to need the full project data anyway in order to display the page the quick toggle UI control was on (wouldn't make sense to send the user somewhere else) so getting the whole project back, setting some values, updating the database, then displaying the projects settings to the user would be just as effective as setting up the project object with just my values, updating the database, fetching the project details, then displaying them to the user. while I am sure there might still be some small times where I would only want to update a specific portion of the record without the overhead of downloading the entire record, it seems, after further consideration, that the times when I would need/want to do that are less than I initially suspected. Thanks, Bill On 2/9/06, Joe Rinehart <[EMAIL PROTECTED]> wrote: Hey Bill, Either way (allowing partial commits or not), the bean is still going to be fetched and populated - that's just kind of the breaks of dealing with things as objects instead of writing ad-hoc SQL.  It's not as granular, but it's also more powerful. If you do allow a partial commit from the "settings" interface for the project, you'd likely have something like this (assuming Model-Glue (or Mach-II) event-bean utility): project = project.load(projectId=projectId) project.makeEventBean(project) project.save("settingOne,settingTwo") Without a partial commit, it'd just be this: project = project.load(projectId=projectId) project.makeEventBean(project) project.save() That'd execute the (slightly more efficient) "partial" SQL that just updates settingOne and settingTwo.  However, it's violating the DRY (don't repeat yourself) principle that frameworks like Reactor help implement.  If you don't allow partial commits, you can add settingThree by just adding a new database column and UI:  the "full stack" nature of combining Reactor with Model-Glue or Mach-II makes this possible, because your Controller code doesn't know anything about columns. In the end, everything's a tradeoff. -Joe -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask.