RE: Reactor For CF Update single value

[Chris Terrebonne]

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.