GetMetaData() Is Shared By All Instances Of A Given Class In ColdFusion
This is just a minor note, but I found out the other day that the structure returned from ColdFusion's GetMetaData() method is not unique to the instance on which it was called. Rather, the structure seems to be shared among all instances of a given class (component definition). This means that if you update the Meta Data for a given CFC instance, it updates the Meta Data for all instances of the same time. And what's more, this has nothing to do with the persistence of any of the objects in question. Even if you do this on a page where the object is not cached, newly created instances of the given component on subsequent page requests will still have the updated meta data. And, on top of that, the Meta Data does not seem to be related to the application timeout. I guess the meta data for a given class gets stored in the trusted cache or something?
To see this in action, take a look at the following code:
<!--- Create a test component. --->
<cfset firstTest = createObject( "component", "Test" ) />
<!--- Create another test component. --->
<cfset secondTest = createObject( "component", "Test" ) />
<!---
Now that we have two instances of our test component,
update the meta data for just one of them.
--->
<cfset getMetaData( firstTest ).forBlog = true />
<!---
Output the meta data for both components to see how
they were updated.
--->
<cfdump
var="#getMetaData( firstTest )#"
label="First Test Object"
show="name,forblog"
/>
<br />
<cfdump
var="#getMetaData( secondTest )#"
label="Second Test Object"
show="name,forblog"
/>
The actual component here is empty, which is irrelevant. What's important to notice is that I am creating two separate instances of the component, but only changing the meta data on one of those instances. When they are then both CFDump'd out to the page, we get the following output:
As you can see, the meta data for both of the ColdFusion component instances now contains the "forBlog" key even though only one of the instance' meta data was directly updated.
This is a really minor piece of information; but, I recently started playing around with meta data and this minor point became an important caveat to understand. Perhaps more on this later.
Want to use code from this post? Check out the license.
Reader Comments
woow ben, you discovered the Singleton design pattern....way to go buddy !
yes yes yes!
I came across this exact same thing when working with my CFproperty Inspector code (cfproperty.riaforge.org) when working with sniffing for component properties.
This gave me some bad ideas about implementing (via coldspring) on-demand property manipulation at run time - which would essentially introspect the component, automatically update the properties of the component dynamically (based on your getter methods), and then once setup, be available to flex for Class binding etc.
I opted for writing these properties directly to the component instead, as cfproperty tags and updating them easily via Bolt's Extensions with a simple right click 'Inspect CFC' instead. (bolt extension also found on riaforge) This way you'd have more granular control over those properties that were 'meta data' in the component - but comes with some 'upkeep' in keeping this data aligned with your methods every time you add new getters.
Fun stuff -
@Billy,
I wouldn't say that I discovered the singleton pattern; what I did was find out that meta data for a given class is a singleton, probably creating at first compile of the code, and then shared by all instances of the class. I also figured out that it was:
A) Not created via reflection for each instance.
B) Persistent.
Although, that makes me wonder - would changing the structure of the CFC at run time change it's meta data. You've given me some more stuff to experiment with!
@Kevin,
Yeah, writing directly to the CFC would probably be the best move. Oddly enough, I actually stumbled upon this with meta data about Function objects, not components, where there is no option to write directly.
Interesting... It seems the meta data is being stored with the template proxy cache. I guess they figured it wouldn't change much and people wouldn't try to modify it...
The cache hangs around until you run:
createObject('component','CFIDE.AdminAPI.runtime' ).clearTrustedCache('/full/path/to/your.cfc');
Or click the Clear Template Cache Now button on the Caching page in your cf admin.
@Mike,
Interesting. So, I guess the meta data won't change if the CFC is changed at runtime. It's worth looking into.
I'm hoping for: THIS.enableAppTrustedCache & clearAppTrustedCache()
@Aaron,
Clearing the trusted cache would be interesting. I am not 100% sure of all the things that go in the trusted cache. Are these basically the compiled templates and CFCs?
Sry for the late reply. Yes, pretty much. "Template Cache" is the place in memory where compiled CFM and CFC templates are stored. When the "Trusted Cache" box is checked, in the Admin, CF doesn't inspect these requested templates for updates.
This is server-wide tho (w/ a "Clear Template Cache Now" button in the Admin). I'd like to leave Trusted Cache enabled, but have ability to "reset" a specific app's portion of this cache after uploading an updated .cfm or .cfc.
I also found one of Ahwin's blog posts pretty informative: http://blogs.sanmathi.org/ashwin/2006/07/12/tangling-with-the-template-cache/
I must clarify that the Admin API does provide ability to clear individual templates from the cache.. What I meant, was that I want to be able to just update and upload any number of templates (such as via FTP), and then simply call the clearAppTrustedCache() function.
@Aaron,
Ah, ok that makes sense. Seems like it would be a cool feature to have.