On Jan 10, 2008, at 12:48 PM, Eric Butera wrote:

> On Jan 10, 2008 1:33 PM, <reese@adeptscience.com> wrote:
>> I have been using define to create a constant for the link resource
>> returned by mysql
>> pconnect like so:
>>
>> $PL = @mysql_pconnect("localhost", $DBUser, $DBPass);
>> define("SITE_DB",$PL);
>>
>>
>> Later I use the constant to select my databases.
>>
>> mysql_select_db($SrcdbID ,SITE_DB);
>>
>> This code seems to be working as I expected and I have many
>> thousands of llines of code
>> done over several years using this construct.
>>
>> But, I happened to be reading the php doco today and noticed that
>> you are not supposed to
>> use define for resources, so question is, is what I am doing safe
>> or am I going to run into
>> problems and if so what is the best way to globally pass resources
>> to multiple classes and
>> functions, command line scripts etc?
>>
>>
>> Cheers
>> Charlie Reese
>>
>>
> Hi Charlie!
>
> Well a CONSTANT is a value that doesn't change. I don't think that
> makes sense for a DB connection. The connection command returns a
> resource that could be different on each request depending on if
> you've worked on different resources.
>
> You could just do this:
> $GLOBALS['SITE_DB'] = @mysql_pconnect("localhost", $DBUser, $DBPass);
>
> Then inside your function reference it like this:
> mysql_query($sql, $GLOBALS['SITE_DB']);
>
> This would be an easy mass find/replace that you could do. Global
> variables are evil though.
>
> I personally use the registry pattern to hold an instance of the
> database connection that can be lazy loaded whenever I need it. Then
> inside of my gateway objects I pass that instance in the constructor
> so they only have to know how to work with its interface. If you're
> okay with using object that might be a nice road to travel. You could
> also use the singleton pattern but I would advise against that because
> what if you wanted 2 instances for different databases? I've never
> ran across this myself but you never know. Plus it makes unit testing
> a little tricky since you can't mock it as easily.
>
> Hopefully something in all this will help you to an answer.


I don't agree that "Global variables are evil." If you have a valid
purpose for defining a global variable, then go with it. The usual
argument is that it could accidentally be changed elsewhere (and there
are several more). However, defining a variable that you KNOW you're
going to use only for a database connection, IMO, is perfectly fine.

$GLOBALS['SITE_DB'] = @mysql_pconnect("localhost", $DBUser, $DBPass);

If you accidently change $GLOBALS['SITE_DB'] elsewhere, then I think
you have some bigger issues at hand. =P HTH.

~Philip

"Personally, most of my web applications do not have to factor 13.7
billion years of space drift in to the calculations, so PHP's rand
function has been great for me..." ~S. Johnson