Is it save to rely on ini_set() for MySQL credentials?

[ttocskcaj]

In MVC type architecture, is it safe to do this

ini_set("mysql.default_host"$mysql_host);
ini_set("mysql.default_user",$mysql_user);
ini_set("mysql.default_password",$mysql_pass);

in my index.php file.

 

Then, every time time I do a query in a model,

 
mysql_connect(); // MySQL connects using the default values from the ini_sets we did.
mysql_query($query);
mysql_close();

 

The reason behind this, would be to avoid passing database variables to objects/models etc or defining constants.

 

Maybe there's a better way? I'm looking into database abstraction.

[RussellReal]

Honestly, you're going to be creating tons of constants anyway.. etc:

 

OPTIONS_TABLE

USERS_TABLE

 

because when you move your app from 1 site to another, it may or may not be shared and shared hosting usually prepends your table names, or database names..

 

and tbh, runtime ini changes are superficial changes, so most php installations should allow this behavior, but, it makes no sense not to keep the static information in a constant, hence the name "constant"...

 

and constants are always in the global scope, so, no need to pass other objects into newer objects..

 

Furthermore, you shouldn't need to do the above either way, more than once, if you're extending other, more top level classes..

 

for example.

 

class User extends DBClass {

}

 

or you could create an object factory.. either way, the only thing you're doing by not using constants, is probably creating a very frustrating application (Magento?)

 

I hope I helped,

 

Russell

[ttocskcaj]

My queries are mostly like this:

SELECT * FROM `" . DB_PRE . "messages`...

where DB_PRE is the prefix for table names defined in the config file. So I shouldn't have any need to table name constants. But I see your point.

 

I've discovered that if I run mysql_connect() at the start of execution, the connection stays available in objects and stuff anyway, so I really only need to do mysql_connect() once. Correct?

[RussellReal]

more than likely yes, I suppose thats true too..

 

However you work it, I mean, I'm just saying you're probably better off constanting all constant data, even error messages should be constants that or in 1 long csv file or something, because the ultimate goal of an MVC is portability, and having a centralized message/language file, and easy to modify, familiar, simplistic code configuration will make your MVC stand out more.

 

[ttocskcaj]

Yup. It's a forum CMS. So it supports different styles (the name of the style is a constant already )

There's a language class, that stores all the language strings in an array. Including, eventually, error messages etc. If that's what you're meaning.

Having different language strings in constants might not work, because there may be hundreds, even thousands of them. That's lots of constants to define and keep track of..

[cpd]

I personally prefer to manage my connections through variables not by setting the default information. This ways when you create multiple connections you can standardise your connection method.mdefaulting the host is okay but once again you may use multiple hosts.

 

For this reason I choose not to use the ini_set for connections. That said, it has it's purpose so if you want to make use of it you can.

[trq]

ini_set doesn't actually set the option within the ini file. It only changes the option for the life of the page it is called on.

[ttocskcaj]

ini_set doesn't actually set the option within the ini file. It only changes the option for the life of the page it is called on.

 

Yup I did realise that haha. But that doesn't matter since ini_set() is called every time a page is loaded anyway.

 

I think we're going to move to PDO anyways.

[RussellReal]

ini_set doesn't actually set the option within the ini file. It only changes the option for the life of the page it is called on.

 

thats what I meant by 'superficial'.

 

IDK If your post was in reference to him or me