Using multiple data sources

2 views
Skip to first unread message

iKnowKungFoo

unread,
Jul 7, 2009, 11:48:42 AM7/7/09
to ColdSpring-Users
Ok, so I've been writing my own ObjectFactory.cfcs for a while and
I've finally got a rewrite project where I can essentially start from
scratch. Currently, I set this in my onApplicationStart():

application.dsn = structNew();
application.dsn.one = "one";
application.dsn.two = "two";
application.dsn.three = "three";

then pass that struct into the init() method of any CFC that needs it
as a single argument.

The quickstart uses a single ConfigBean.cfc to set and inject a single
datasource into the singletons that need it. What's the best way to
handle multiple DSNs with ColdSpring? Multiple ConfigBeans or a single
ConfigCollection.cfc that encapsulates the struct with altered methods
like getDatasource("one")?

I'm not using Transfer or any MVC framework (yet). I'd just like to
get CS wired up correctly.

Thanks.

Brian Kotek

unread,
Jul 7, 2009, 2:06:44 PM7/7/09
to coldspri...@googlegroups.com
You can do it either way: have separate config beans, or have one config bean that you can pass in and call a method on to get the relevant DSN settings. I'd probably argue that you should use separate config beans, that way you can swap out the datasource settings just by changing the ColdSpring XML file, rather than forcing your code to "know" which DSN it should be using.

iKnowKungFoo

unread,
Jul 7, 2009, 2:37:08 PM7/7/09
to ColdSpring-Users
I found the entry on dynamic properties, then found out that those
properties have to be simple values (i.e. no structs).

So my question is then, separate config beans or dynamic properties?
Knowing that I can update the coldspring XML using either, which is
the better approach? I'm leaning towards dynamic properties just to
avoid creating more beans, but that means editing the main
Application.cfc whenever I want to make a change to the DSN.

Decisions, decisions . . .

On Jul 7, 1:06 pm, Brian Kotek <brian...@gmail.com> wrote:
> You can do it either way: have separate config beans, or have one config
> bean that you can pass in and call a method on to get the relevant DSN
> settings. I'd probably argue that you should use separate config beans, that
> way you can swap out the datasource settings just by changing the ColdSpring
> XML file, rather than forcing your code to "know" which DSN it should be
> using.
>

Barney Boisvert

unread,
Jul 7, 2009, 2:46:20 PM7/7/09
to coldspri...@googlegroups.com
I wrote a simple "flattener" that will take nested structs and
collapse them so ColdSpring can dereference them. So if you have this
struct:

config = {
dsn = {
one = "onedsn",
two = "twodsn"
}
};

it'll convert it into this:

config = {
dsn = {
one = "onedsn",
two = "twodsn"
},
"dsn.one" = "onedsn",
"dsn.two" = "twodsn"
};

Here's the code:

<cffunction name="prepForColdSpring" access="public" output="false"
returntype="struct"
hint="I collapse all nested structs into dot-delimited top-level keys">
<cfargument name="config" type="struct" required="true" />
<cfset prepForColdSpringInternal(config, "", config) />
<cfreturn config />
</cffunction>

<cffunction name="prepForColdSpringInternal" access="private"
output="false" returntype="void">
<cfargument name="root" type="struct" required="true" />
<cfargument name="path" type="string" required="true" />
<cfargument name="config" type="struct" required="true" />
<cfset var i = "" />
<cfloop collection="#config#" item="i">
<cfif isStruct(config[i])>
<cfset prepForColdSpringInternal(root, listAppend(path, i, "."),
config[i]) />
<cfelseif path NEQ "">
<cfset root[listAppend(path, i, ".")] = config[i] />
</cfif>
</cfloop>
</cffunction>

cheers,
barneyb
--
Barney Boisvert
bboi...@gmail.com
http://www.barneyb.com/
Reply all
Reply to author
Forward
0 new messages