storing variables in $_SERVER

[Brian W]

Why (if it is) bad practice to use the $_SERVER array to store variables like the database hostname, username, password, etc... or even a mysqli object?

 

I know the whole anti lazy coding, but is there another reason not to go about things like this?

[trq]

Storing anything within the $_SERVER array will not persist through multiple requests so you may as well just use a normal array.

[Brian W]

advantage of global access... right?

[trq]

Globals are bad in anyone's books.

[Brian W]

the question I guess is "why"? Whats the issue with using a $_SEVER to store a connection object to access globally to avoid reopening the same connection repeatedly?

[Pikachu2000]

Are you sure you aren't referring to $_SESSION variables?

[Brian W]

although I misspelled it is a previous post, I do mean $_SERVER... you know, the one with HTTP_HOST & DOCUMENT_ROOT along with a bunch of other information about the machine and the file you're working with.

[Pikachu2000]

For what purpose would you consider doing that?

[trq]

You really need to explain your question. The $_SERVER array is just like any other array accept it comes pre-populated with some variables based on your environment. You can't exactly *store* anything in it. Nothing that will persist across requests anyway.

[micmania1]

The only benefit I see is to save memory - although the saving is hardly worth the work. I suppose you have the global factor too.

 

Instead of server though, there is an array called $_ENV.

 

 

Try the following 3 small scripts to view memory usage:

<?php
putenv("TEST=1");
echo memory_get_usage();
?>

 

<?php
$test=1;
echo memory_get_usage();
?>

 

<?php
$test="1";
echo memory_get_usage();
?>

 

I'm not sure if putenv() saves as bool or int, hence the reason I done the two scripts for $test variable - both with different memory usage.

 

You can access the variables in two ways.

 

echo $_ENV['TEST'];

 

echo getenv('TEST');

 

 

I don't know why using these techniques would be classed as bad practice. Maybe its just some sort of unofficial standard?

[Brian W]

Interesting, $_SERVER is quite bulky...

My Results

Base	83144
putenv	83496
1	83552
"1"	83584
$_SER	94896

 

Multiple uses of $_SERVER did not increase the memory usage noticeably, but that first time does jump it. So PHP seems to ignore populating it unless you actually use it in your code.

 

putenv doesn't seem to be required to drop stuff into the $_ENV global. I did this little test this morning:

<?php
$obj = new stdClass();
$obj->name = 'test';
$_ENV['obj'] = $obj;
function test(){
    echo $_ENV['obj']->name;
}
test();
?>

 

The memory usage is lower than $_SERVER (86632) but if you plan on using $_SERVER anywhere in your code you will end up using the memory.

 

For a programming convention, not that globals aren't still under scrutiny, is a database connection more of a $_SERVER thing or a $_ENV?

[trq]

For a programming convention, not that globals aren't still under scrutiny, is a database connection more of a $_SERVER thing or a $_ENV?

 

Your still missing the point. You could use a normal self created array. $_SERVER does not persist content you have added to it across requests. $_ENV will if you actually add these values to your environment through Apache directives.

[Brian W]

I know that... your missing my point. The idea isn't to carry it over multiple requests, but to have access to the same connection inside all of my objects on all scopes.

[btherl]

$_SERVER has a special meaning - it contains "server variables".  If you put other things inside there then you are changing its meaning.  This will confuse other programmers who modify your code later.  It also may break code written by other people which you integrate into yours, as they may assume that $_SERVER is used for its intended purpose only.

 

If you will be the only programmer who ever uses your code, then I don't see any problem with using $_SERVER that way.  But if I ever maintain your code, the first thing I will do is take those variables back out again   It's a maintenance time bomb.

 

If you want a global variable, you can create your own.  There's no need to use an existing superglobal.  It would be convenient if PHP allowed user defined superglobals, but probably a bad idea, as I think it's better if you're forced to declare globals in each function you use them, which clarifies what external variables that function needs.

[trq]

So your looking for a global location to store a connection? IMO you would be better of creating a connection factory that on first call creates a connection, subsequent calls return that same connection.

[Brian W]

Drupal uses the $_SERVER superglobal to store connection information (though not the connection object itself that I know of). This does seem to be a valid use as what you are storing is the connection information for the mysql server. Maybe not, maybe Drupal's architects are missing the point too.

 

Using mysql_connection(), you can use most any of the mysql_* functions without passing in the connection resource which makes it an easy choice... mysqli however isn't as friendly, though its so much faster and (imo) fits in with oop better. From my understanding, using the persistent option with mysqli will cache the connection and reuse the same connection repeatedly until the request is done. If this is true, a factory wouldn't need to access a global connection object because their would be very little resources sacrificed for mysqli to return the cached connection repeatedly.

 

I'm thinking that using a persistent connection and storing hostname, username, password, and database in $_SERVER is the solution, but then again I'm not all that familiar with building factories... I did see a tutorial using the "singleton" structure, but didn't fully get it I guess. Maybe someone has a link to an awesome singleton for mysqli

 

Thanks for all the input!

[trq]

Drupal uses the $_SERVER superglobal to store connection information (though not the connection object itself that I know of). This does seem to be a valid use as what you are storing is the connection information for the mysql server. Maybe not, maybe Drupal's architects are missing the point too.

 

Drupal is definitely not the first thing that comes to mind when I think about well designed applications.

 

I'm thinking that using a persistent connection and storing hostname, username, password, and database in $_SERVER is the solution

 

Have you ever heard of constants? These are perfect for storing simple strings and accessing them from anywhere.

 

I did see a tutorial using the "singleton" structure, but didn't fully get it I guess. Maybe someone has a link to an awesome singleton for mysqli

 

There is an entire series covering the basic design patterns on our main site (http://www.phpfreaks.com/tutorials/page2). There's an article there covering the singleton.