|
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. > 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. > 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'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. >
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. > 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. >
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? Thanks again
for the response. No hitting. Just a friendly debate. ;) Thanks, Chris -------------------------------------------------------------------- On Feb 21, 2006, at 2:27 PM, Chris Terrebonne wrote:
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 |
- RE: [Reactor For CF] Mapping question Jared Rypka-Hauer
- RE: [Reactor For CF] Mapping question Gabriel Roffman
- RE: [Reactor For CF] Mapping question Cody Caughlan
- RE: [Reactor For CF] Mapping question Chris Terrebonne
