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

[Jared Rypka-Hauer]

OK, I'm gonna start a new set of comments here because it was getting too hard to follow. I do have to say, though, that you're already reading the whole record. The DB is already re-writing that whole record back to itself. NO MATTER how few columns you ask it to change the values for, you've already exposed the entire row to entropy simply by asking it to set fname= 'Jared'. You've edited the whole record. Check the logs... at least in SQL Server it re-writes the whole record to the DB anyway. You've involved the whole row in an exchange with a CF object... my major point is the fact that, while you might feel "safer" by only SENDING the DB one or two columns out of 10 or 20, that perception of safety is illusory. The need to be able to say "I am only writing to 2 columns" to satisfy a manager's craving for comfort, false as it may be, is probably justification for doing something silly ;) like putting a state machine in every bean. What I'm trying to convince you of here that what you're proposing is, essentially, building a false sense of security into the framework. Think of it like a security guard at the bank... everyone feels better, but in the even of a real robbery you're probably up a creek anyway. Because of the way the DB works for both updates AND inserts, the ROW IS THE ATOMIC ENTITY. Columns are irrelevant because they're all touched on every request for inserting or updating... you can't escape it. Regarding frameworks, though... a good framework should be able to maintain a fairly constant performance level across a broad spectrum of loads while NOT sacrificing  performance (but then semiconductors should work at room temperature, too). Case in point, Fusebox. It incurs 0 overhead once you've hit the page the first time. MG and Mach-II are already doing work that has to be done in code somewhere, they've just organized it to enhance reusability. Reactor shouldn't either, since it's built on top of the concept of beans+persistence patterns, so it also is only doing work that would be done elsewhere in code. So to say we're sacrificing performance to gain maintainability isn't entirely correct. On a busy site with lots of complexity, I see the added weight of the state machine in your beans and the extra operations required to make it work (plus the lack of consistency introduced by not writing to the whole record -- especially with the feature available at runtime!) as far more likely to cause errors than asking a record to write itself and leaving it go at that. Maybe it's just a matter of personal style. Tho' I'm starting to see that used as a catch-all explanation in places where I don't think it's entirely appropriate, it just may be. The ability to randomly pick columns to write to and/or involve state management is, IMO, more likely to introduce bugs and errors into the system than a simple and straightforward "I have data. Write data to DB." You're talking about wanting to keep things simpler by making them far more complicated... which feels extremely counter-intuitive. What it comes down to is this one question: How many people need this in order to be able to use Reactor in their jobs? If enough people *have* to have it I'm sure it'll get incorporated eventually... it sux to have programming decisions forced by the business side of things... but sometimes you gotta do what you gotta do. I can't make any statements on behalf of Doug, however, so while this conversation has been stimulating it just may be entirely academic unless numbers and/or arguments can be made to sway Doug. Anyway, I think I've pretty well exhausted anything I had to say on the topic... we'll just have to wait and see what comes of this particular suggestion as time goes on. Laterz! J ------------------------------------------------ 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