Blog

ColdBox 4.0 Dealing With Datasources

Brad Wood February 19, 2015

Spread the word

Brad Wood

February 19, 2015

Spread the word


Share your thoughts

ColdBox allows you to store the details of your CF datasources in your configuration file.  This prevents you from needing to store usernames and passwords in  your actual code, and allows you  to easily switch an application to another database, even with the environment control.  In  the past this datasource information was presented to you as a CFC object with getter methods.  

In ColdBox 4.0 we recognized that the datasource bean was really just a value object with no behaviors-- only data.  In the spirit of simplification,  we've replaced the datasource bean with a standard struct of data.  It contains the same information, but instead of calling a getter, just reference the keys in the struct.  An extended find and replace on your app's code base should made quick work of this.

Here's an example of what your code might have looked like on ColdBox 3.x


<---  Dependencies --->
<cfproperty name="dsn" inject="coldbox:datasource:mydsn">

<---  list --->
<cffunction name="list" output="false" access="public" returntype="query" hint="Return the contacts">
	<cfset var q = "">
	
	<cfquery name="q" datasource="#dsn.getName()#">
	SELECT * 
	    FROM contacts
	ORDER BY name asc
	</cfquery>
	
	<cfreturn q>
	
</cffunction>

And here's that same code ready for ColdBox 4:


<---  Dependencies --->
<cfproperty name="dsn" inject="coldbox:datasource:mydsn">

<---  list --->
<cffunction name="list" output="false" access="public" returntype="query" hint="Return the contacts">
	<cfset var q = "">
	
	<cfquery name="q" datasource="#dsn.name#">
	SELECT * 
	    FROM contacts
	ORDER BY name asc
	</cfquery>
	
	<cfreturn q>
	
</cffunction>

You'll note the only difference is dsn.getName() turned into dsn.name.  Your /config/ColdBox.cfc file will look the same as always.  No changes there!

Add Your Comment

Recent Entries

One Language, Every Runtime: BoxLang Expands Beyond the Server

One Language, Every Runtime: BoxLang Expands Beyond the Server

Discover how BoxLang’s multi-runtime architecture helps developers build beyond the server with support for serverless functions, desktop applications, CI/CD workflows, Java integrations, containers, runtime management, and more.

Maria Jose Herrera
Maria Jose Herrera
June 04, 2026
MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

MatchBox and WebAssembly: Running BoxLang in the Browser and at the Edge

The MatchBox open beta is live at https://boxlang.ortusbooks.com/boxlang-framework/matchbox, and it brings something genuinely new to the BoxLang ecosystem: a path into WebAssembly.

That means BoxLang code can now move into browser applications, static-site deployments, edge runtimes, and WASI-style containers - without requiring a JVM. The feature is still beta, but the core direction is already useful: write BoxLang, compile it with MatchBox, and ship the generated WASM artifact to wherever a small portable runtime makes sense.

Jacob Beers
Jacob Beers
June 04, 2026
BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 : BoxSet is Here: BoxLang's New First-Class Set Type

BoxLang 1.14.0 ships something that JVM developers have wanted for a long time: a true first-class Set type baked directly into the language. Not a wrapper you reach for manually, not a createObject( "java", "java.util.HashSet" ) incantation you paste from a Stack Overflow answer years ago. A real BoxSet with literal syntax, operator overloads, a full functional pipeline, change listeners, JSON serialization, and deep Java interop.

Luis Majano
Luis Majano
June 03, 2026