RE: [Reactor For CF] Mapping question

[Cody Caughlan]

The handling of NULLs can be a big problem. I was dealing with the same issue when I was working with SugarCRM's object persistence layer. Since it doesnt have selective updates and its an "all or nothing" affair, you end up updating stuff with empty strings where you would really want it to be NULL. Not that I am claiming it to be a nice solution, but per object/per table, it would be nice if there was a mechanism to say, if this propery is the empty string or "-1" then assume NULL instead during the UPDATE. There are obvious flaws with this approach but *something* like that would be in order.   /cody From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Roffman Sent: Tuesday, February 21, 2006 1:34 PM To: reactor@doughughes.net Subject: RE: [Reactor For CF] Mapping question I haven't tried this yet, but what happens with null column values when you update the row this way?  Do they get converted to zero length strings?   Gabe Roffman eTesters   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jared Rypka-Hauer Sent: Tuesday, February 21, 2006 4:13 PM To: reactor@doughughes.net Subject: RE: [Reactor For CF] Mapping question Chris... Be patient with me... I can be dense once in a while. :D If you keep explaining things, I usually catch on. I'm not trying to be a jerk here, I just honestly don't understand how the work involved in making the objects aware of and able to manage their own state to the degree of granularity you're suggesting is worth it. 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. I'm also not sure that it "conforms more neatly to OOP standards" because I'm not sure there's an OOP rule about what you should update when other than some specific design patterns. Besides, if you're updating a row, then you've already read data in from that row, right? 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. 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. 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. They're 2 different things, really. I'm not sure, but I suspect that if you connected to a DB as a user that has restricted access to a particular set of columns, when Reactor creates the objects based on that connection you'd only get the columns you can use (that's totally a guess). In that case, using a separate user to handle those transactions is a perfectly valid solution to your problem. 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. 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. Selective updates just seem to be a huge amount of work for limited gain when there are viable alternatives (which, on top of everything else, includes putting custom code in your Reactor objects). Thoughts? Reactions? Watermelons? ;) Laterz, J PS - Don't hit me, please! :) ------------------------------------------------ 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 2:27 PM, Chris Terrebonne wrote: Honestly, if there was no purpose to it then why does every db on the planet provide that functionality?  There is a basic QA issue that comes into play when interacting with enterprise systems in that manner.  For example, if I am writing a CF extension to our corporate accounting app, there is no way I would just arbitrarily update an entire row just because that method more neatly conforms to OOP standards.  I don’t care how confident I am in the code, there are just some fields that should be considered “protected” and should not be handled.  I realize that it’s not necessary to be that paranoid about all apps, but for a corporate accounting app, there’s no way I would survive a code audit any other way. YMMV, Chris -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/ -- Reactor for ColdFusion Mailing List -- reactor@doughughes.net -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/