-----Original Message-----
From: Seth MacPherson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 2:14 PM
To: [email protected]
Subject: RE: [CFCDev] Storing DSN parameters in a "global" variable
Allow me to comment on this one...
Locking an entire query is a really poor choice as well -
particularly a named lock as used in the example.
Application scoped variables should be locked using
<CFLOCK SCOPE="APPLICATION"....></CFLOCK>
And if you need to access an application variable, as in the
cfquery example, you're far better off setting a local
variable like so.
<cflock type="READONLY" scope="APPLICATION" timeout="5">
<cfset myDsn = application.myDsn />
</cflock>
<cfquery name="myQuery" datasource="#myDsn#">
SELECT Blah
FROM Whah
</cfquery>
The result is a very quick read and you're not going to cause
a race condition when your query takes a long time to execute.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 10:53 AM
To: [email protected]
Subject: RE: [CFCDev] Storing DSN parameters in a "global" variable
That's actually not good practice. If you use the
Application scope in the query, you're "supposed" to lock the
scope around the query.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Lyons, Larry
Sent: Wednesday, March 22, 2006 1:48 PM
To: '[email protected]'
Subject: RE: [CFCDev] Storing DSN parameters in a "global" variable
Cody ,
I typically set the DSN and similar params in a "global"
variable. However, one thing to consider when storing DSN
parameters is do these parameters change all that often? If
not then why place these variables in the request scope? By
setting these params in the Request scope you set it and
reset it for each and every page request. It would seem to me
that the application scope is more appropriate for parameters
that rarely, if ever change.
Here's how I handle these params, using your example:
<cfif not structKeyExists(application,"DSNParams")>
<cflock name="appParamsLock" throwontimeout="yes"
timeout="60" type="exclusive">
<cfset application.DSNParams = structNew()>
<cfset application.DSNParams.DSP = "myDBPassword">
<cfset application.DSNParams.DSN = "myDSN">
<cfset application.DSNParams.DST = "ODBC">
</cflock>
</cfif>
Then later on in deepest darkest Code land:
<cfquery name="foobar"
datasource="#application.DSNParams.DSN#"
username="#application.DSNParams.DSU#"
password="#application.DSNParams.DSP"
type="#application.DSNParams.DST#">
select Dunno
from whoCares
where apathy = "true"
</cfquery>
hth,
larry
--
Larry C. Lyons
Web Analyst
BEI Resources
American Type Culture Collection
email: llyons(at)atcc(dot)org
tel: 703.365.2700.2678
--
-----Original Message-----
From: Cody Caughlan [mailto:[EMAIL PROTECTED]
Sent: Wednesday, March 22, 2006 12:53 PM
To: [email protected]
Subject: [CFCDev] Storing DSN parameters in a "global" variable
Is there anything inherently wrong with storing your DSN
parameters in a Request-scoped structure and referring to
these in your cfquerys, e.g.:
<!--- pseudo-code --->
App.cfc::onRequestStart() {
Request.DSU = "myDBUser";
Request.DSP = "myDBPassword";
Request.DSN = "myDSN";
Request.DST = "ODBC";
}
.... later, in some code deep in your app...
<cfquery name="foobar" datasource="#Request.DSN#"
username="#Request.DSU#" password="#Request.DSP"
type="#Request.DST#">
....
</cfquery>
Apart from the encapsulation this *does not* give you, is
there anything wrong with this? That is, your code is now
tied to the Request scope. I
*know* it would be much better to pass every DSN struct into
your CFC that needs it (possibly using some kind of a
centralized object factory like ColdSpring). I have a fellow
developer who prefers this "global" approach. I say its bad,
he says its OK, because Macromedia (now Adobe) will never
take away the the REQUEST structure, so its not like the code
will ever break. My argument is that its not "proper coding",
his argument is the magnitude of convenience this affords.
Whats the right answer?
Thanks
/Cody
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [email protected] with the words 'unsubscribe cfcdev' as
the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
This electronic communication, together with any attachments,
may contain information that is legally privileged,
confidential or otherwise private. The information is
intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient,
please be aware that any disclosure, copying, distribution or
use of the contents of this communication or any attachment
is strictly prohibited. If you have received this
communication in error, please immediately notify the
original sender and delete the received information from your
system. Thank you.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [email protected] with the words 'unsubscribe cfcdev' as
the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [email protected] with the words 'unsubscribe cfcdev' as
the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [email protected] with the words 'unsubscribe cfcdev' as
the subject of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by
CFXHosting (www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
