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

Chris Terrebonne Wed, 22 Feb 2006 10:51:48 -0800

Jared,

Great comments once again. We’ll figure this thing out yet.

You can’t blame Doug for being a bit feisty sometimes. Hell, the guy busted his ass to make something useful, gave it away, and now he has people banging on his door wanting more. Yea, that’ll do it alright. ;)

Again, I’ll continue my comments inline (as if this post wasn’t already difficult to read)

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.

Not sure that this performance rebuttal applies when talking about frameworks. Frameworks, by their very nature forgo performance for flexibility and reuse. Not to mention that the additional footprint would be negligible at best. One way that this could be accomplished would be to represent each column as a structure rather than a single value var.

ID = createValue(“ID”,0,”numeric”,false,false,false);

val newValue = structNew();

newValue.Name = arguments.Name;

newValue.Value = arguments.Value;

newValue.Type = arguments.Type;

newValue.isNull = arguments.isNull;

newValue.hasChanged = arguments.hasChanged;

newValue.isKey = arguments.isKey;

newValue.cfType = getCFType(arguments.Type);

return newValue;

</cfscript>

</cffunction>

Then, when the DAO updates, it can do something like this:

UPDATE #Convention.FormatObjectName(getObjectMetadata(), '')#

SET

#Convention.formatUpdateFieldName('User_ID')# = <cfqueryparam cfsqltype="arguments.to.User_ID.cfType" value="#arguments.to.User_ID.Value#" null="# arguments.to.User_ID.isNull#" />

</cfif>

WHERE

#Convention.formatUpdateFieldName(i)# = <cfqueryparam cfsqltype="#arguments.to.getColumn(i).cfType#" value="#arguments.to.getColumn(i).Value#"/>

</cfif>

</cfloop>

</cfquery>

</cffunction>

Obviously that is half-baked and untested code, but it’s an option and the overhead is minimal compared to the gains. This can be taken a step further by creating the columns as column objects rather than just structs. Granted, that would add a performance hit from the instantiation of the column objects, but it would also add a great deal of flexibility

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.

“IF” . “Should”… by the very fact that you chose those words helps illustrate the uncertainty and volatility that applications introduce. Sure, testing “should” alleviate most errors, but unfortunately, not all. If initial testing was full-proof, there would be no need for patches, hotfixes, or point releases. Bugs are real. I know people who have seen them. ;)

But if you haven't changed it, then it hasn't been manipulated.

But you have changed it. The shear fact of rewriting the same value changes that columns state while introducing entropy. Untouched, its state is static. When written to, its state is now volatile and subject to the imperfections of the application performing the write. The volatility in the system is independent of the data being written. Changing the state of a column increases the probability for error.

Granted, no one is going to store data away forever and never use it for fear of corruption, that would be a bit overkill. But for systems where small errors can have big impacts, simple steps should be taken to minimize the data’s exposure to volatile environments – i.e. only update the columns that are required.

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.

Hell yea I’m worried about that. See “Bug” paragraph above. ;)

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.

Agreed.

Thanks again for the contributions.

Regards,

Chris

-- Reactor for ColdFusion Mailing List -- [email protected] -- Archives at http://www.mail-archive.com/reactor%40doughughes.net/

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

Reply via email to