[Reactor For CF] "Selective Updates" (was Mapping Issue)

[Jared Rypka-Hauer]

Ahh, we're all being so polite. Except Doug... and even he says sorry when he does wrong. Online with grownups... what a pleasure. :D More comments inline below: ------------------------------------------------ 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 21, 2006, at 3:45 PM, Chris Terrebonne wrote: Thanks for the response Jared.  My comments are inline.    > I also know how taxing a project like this can be and, since Doug's keeping pretty tight control over things (and justifiably so) it would fall to him to either delegate and manage (or to code on his own) the bits to do what you're asking for.   Just to clarify, I’m not asking that he add this.  I think that it should be there, but if it’s not, that’s fine too.  Doug has done an awesome job and could stop now with a successful framework on his hands.  If the functionality that I need doesn’t exist, I’ll either add it myself or wait for it to appear.  At this point this is more of a debate than a request. Roger that... I'm all for helping out as Doug has time to review feature requests... I just don't want to see him get overwhelmed with that on top of everything else. Anway, no offense taken, none meant, life is good. Yay!   > Besides, if you're updating a row, then you've already read data in from that row, right?   Not necessarily.  If I’m doing an insert, then this is new data that has not been read.  Also, there is no reason to load all data from the row if I am only updating certain fields.  I would select only the fields I was updating. Ahh but specifically I was referring to "updates" as in "update tblWhosIt set blah = 'foo' so inserts be a whole other aminal. I was making the assumption that, in your example your extension to the accounting system would only be editing existing data in the tables. My bad. Yes, inserts are a whole different beast, but I still don't really see an issue with a "whole record write" if your object only matches a subset of the columns in the table. It's a lot easier to implement than adding a state machine to every bean generated by the framework. That adds to the memory footprint AND the gross operations that all the higher-level operations have to go thru for a simple insert/update query.   > And if you've already read the data in from the row, then change 2 columns and flush the data back into the row, then the only changed data that's written to the DB is changed. The rest is unchanged because you wrote the original data back to the table.   In a perfect, bug-free programming world, then yes.  But unfortunately, like many of you, I don’t live in that world.  The probability of an error in the data is far greater if loaded into an app and then saved back than it is to not touch the data at all.  That is where the QA becomes an issue. I'm  not sure I agree with this... why should there be errors if validation has been written into the system and there's no loss of connectivity? If unit testing, user testing, and load testing have all agreed that the system is sound then any oddball errors should be handled and the rest of the time things should be gravy. And that's not from the perspective of a perfect world, that's from the perspective of someone who uses software every day that works and works and works without blowing up. So I'm not sure why reading and writing from a DB should elevate the probability of errors... I thought that was the whole purpose of databases and middle-ware to begin with. ;)   > I'd also be concerned about "security by proxy"... that is, your system is considered acceptable if only certain columns get updated, but the whole table doesn't get updated because you choose to only update some columns, not because you can't. If that data is *that* critical, it should be in a separate table and/or protected with user-based access control so that you CAN'T write to it without meaning to. Your example smacks of poor DB design.   Yikes.  That is a bit of a stretch.  First, I’m not talking about “protected” in the same regard as user security or access control.  I am simply referring to not manipulating data that doesn’t have to be.  An application is a far more volatile environment than is a static db table.  If that’s bad design, don’t blame me, I didn’t invent either one. But if you haven't changed it, then it hasn't been manipulated. It's "manipulated" when the original state of the object changes for some reason... if it hasn't changed, then a call to write back what was read hasn't changed anything and, frankly, if you're changing one column then the record has been written to... if you're writing to a third of the columns or all of them, you've still locked, opened, altered, committed, and released that row in the table. I can see not wanting to allow people to change certain values in a table, but again, if that's the case then that column should be locked down and the rationale logged in a design document. The thing is, the whole row is locked, opened for write, then concatenated and the whole row is written back to the table anyway... so unless you're worried that your CF code is going to go belly up on you, there's no real point to only sending back a subset of the data in the object.    > I think you're mixing apples and oranges here a bit, too... at one point you're arguing for selective updates and at another for column-level security.   Again, I’m not speaking of column “security” as much as column integrity. Point taken.   > I do see your point about having to survive code audits and deal with corporate policies. If that's the case, I'm not sure that any completely automatic system like Reactor is going to work very well... at some point you're going to have to do something manual just to account for the arbitrary rules that get put in place in situations like that.   Nah, it will work perfectly well as long as the functionality exists, whether that means I wait for it or I make the modification myself.  I don’t think that most framework designers would like their code limited to shopping carts and forums. ;)  The real test of a framework is its use in large enterprise apps. Indeed... but there's always a bit of "sculpting" you have to do in order to make an automated system like this works. What worked wonderfully when you're only using "ad-hoc SQL" (even if it's in explicit SQL queries in a DAO... it's not generated, it's literal) won't work that well when you're working with a framework. "Framework" implies not just pre-fab libraries and methodologies but more often than not some rules too. In this case, those rules may include a bit of your database structure.   >  This brings up a thought though... how hard would be be (and how useful) to have a restrict-columns or just a columns element/attribute somewhere in the XML vocabulary for Reactor (it seems that an attribute on the object tag would be best) that would allow you to specify the columns you wish to grab so that you could only get, say the 5 of the 15 columns in a table? I can think of several uses for this, especially if you wanted a separate User and Address object in your model even thought you have fname, lname, addr1, addr2, city, yadda yadda in the same table. They'd originate from the same table, they'd just have a composite relationship as objects.   It seems that the ability should be available at runtime, and this solution doesn’t appear to allow that.  Am I missing something? Not really... I just don't agree. :)   Thanks again for the response.  No hitting.  Just a friendly debate. ;) Vunderbar! Ausgetzeichnet! Ya! :D   Thanks, You're welcome. Backatcha. Chris J