Yes, I've run into this problem myself while working on my BlogCFC port. BD
essentially treats CFC functions as data within the CFC "this" and
"variables" scope, which means they get serialized with the CFC when writing
to the GAE datastore. If you modify your CFC change the implementation of a
function or add new functions, those changes don't affect CFCs that are
already in the datastore. You'll have to deal with this manually. Two
suggestions to make this easier:
1) Store a "version number" within your CFC "this" or "variables" scope
and increment it whenever you modify the CFC.
2) Create an init() function for your CFC that takes another CFC as the
argument; initialize the CFC by looping through the "this" and "variables"
scopes and copy all the relevant variables. You can use this init() function
to upgrade a CFC.
Something like this:
<cfscript>
oldCFC = googleRead( oldKey );
if ( oldCFC.version = "1.0" ) { // need to upgrade to version 2.0
newCFC = createObject( "component", "MyCFC" );
newCFC.init( oldCFC );
googleWrite( newCFC );
googleDelete( oldCFC );
}
</cfscript>
Vince
On Fri, Jun 5, 2009 at 2:15 AM, Baz <[email protected]> wrote:
> If someone were persisting their cfc's to the datastore, then needed to
> update the code, a problem arises. The cfc's that were stored in the past
> will be de-serialized to old components that are missing new methods and
> code updates that may be needed by the updated app. Does the application
> have to manage the synchronization of cfc's in the datastore?
>
> Baz
--~--~---------~--~----~------------~-------~--~----~
Open BlueDragon Public Mailing List
http://groups.google.com/group/openbd?hl=en
official site @ http://www.openbluedragon.org/
!! save a network - trim replies before posting !!
-~----------~----~----~----~------~----~------~--~---
