Ben Nadel
On User Experience (UX) Design, JavaScript, ColdFusion, Node.js, Life, and Love.
I am the chief technical officer at InVision App, Inc - a prototyping and collaboration platform for designers, built by designers. I also rock out in JavaScript and ColdFusion 24x7.
Meanwhile on Twitter
Loading latest tweet...
Ben Nadel at Scotch On The Rock (SOTR) 2010 (London) with:

GetMetaData() Is Shared By All Instances Of A Given Class In ColdFusion

By Ben Nadel on
Tags: 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:

 
 
 
 
 
 
GetMetaData() Structure Is Shared Among All Instances Of A Given Class In ColdFusion. 
 
 
 

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.



Reader Comments

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 -

Reply to this Comment

@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.

Reply to this Comment

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.

Reply to this Comment

@Mike,

Interesting. So, I guess the meta data won't change if the CFC is changed at runtime. It's worth looking into.

Reply to this Comment

@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?

Reply to this Comment

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/

Reply to this Comment

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.

Reply to this Comment

Post A Comment

?
You — Get Out Of My Dreams, Get Into My Comments
Live in the Now
Oops!
Comment Etiquette: Please do not post spam. Please keep the comments on-topic. Please do not post unrelated questions or large chunks of code. And, above all, please be nice to each other - we're trying to have a good conversation here.