Re: Re: PATCH: Multiple INI files for DB_DataObject

Well, you could specify which ini files you need to loa din each of those masters. Honestly, you're making this very hard on yourself. Why are there so many ini files? If you have one master ini file per database (as I would think you might) then putting that db's table ini files in that master one shouldn't be a problem, right? Maybe you could explain why your system is this way? Joe Stump wrote:

The settings I'm talking about go in the main DataObjects ini file which stores the DSN for the DB connection and such, not the database table ini file. You must have one of those....

I have lots of them :) My setup is a strange one for sure. I have multiple INI files all over the place and I needed to be able to load more than one no matter what my master INI file said. For the record: I have multiple master INI files - a single one is loaded depending on which application is ran, but it varies. --Joe

Joe Stump wrote:

I would think it would be nice to have a standard format for multiple ini files, such as databaseName.N.ini so that _loadDefinitions could load them automatically. This way you can have a database named db1 without running into the db1.ini for the 'db' db. Or possibly another config option to the DataObject.ini as such: multiple_file_format = "DBNAME.%n.ini" with DBNAME being the name of the database and %n being any integer. Then it could replace those vars and load the config files. (The problem here is knowing when to stop looking)

This is no good because this assumes that all of your ini files are in the same path (which is not always the case). The way my patch currently works it allows you to have ini files as such: /path/to/db1.ini /path/to/another/different/db1.ini

This would also work. Multiple entries with a number in them. ini_file_0 = dbname.ini ini_file_1 = dbname1.ini ini_file_2 = dbname.2.ini ini_file_n = ... With this second option, you can specify exactly all of the ini file to load and have multiple formats of ini names (if you want them).

This, again, is no good because it assumes that I have a central INI file, which is not true in my case. For instance, if my main ini file is /path/to/foobar.ini and it loads db1.ini and db1.links.ini, but I have another ini file somewhere else I want to load then I can easily do it with my _appendDefinitions() function, which can be called statically from anywhere to add extra ini files. --Joe

Sidenote: The reason I keep advocating ini file options is to keep configuration out of the source files. If you have to set these in the class every time, it causes extra set-up code ot be added to EVERY project which uses the same DataObjects. You *can* do this in an extended class, but extending a class only for config options isn't (IMHO) a great idea. (Then again, this is just how Smarty works, so...) -paperCrane (Justin Patrin) Joe Stump wrote:

I've attached a diff that fixes my earlier problem (NOTE: evidently attachments don't go to the list - check out http://professorx.jcssolutions.com/~jstump/DataObject-append-definitions.diff). My problem was that I needed to concat 1 -> N database configs into a single [INI] in $_DB_DATAOBJECT. Here is an example setup: (all of these ini files are for a single database: "mydb") /path1/to/database1.ini (contains tables users and test) /path2/to/database2.ini (contains tables foo and bar) /path3/to/database3.ini (contains tables sessions and tester) <?php DB_DataObject::_appendDefinitions('mydb','/path1/to/database1.ini'); DB_DataObject::_appendDefinitions('mydb','/path2/to/database2.ini'); DB_DataObject::_appendDefinitions('mydb','/path3/to/database3.ini'); ?> Now when you load up a PEAR DBDO you should have all three of the above INI definitions in your data object along with whatever definition you have in the data object you are currently using. Also, it keeps track of which ini files it has already loaded and only loads them once. This also slighly alters the behavior of _loadDefinitions() (to use _appendDefinitions()). I hope this helps someone else. If the author wants me to clean this up for submission please email me off list. Flame away! --Joe -- Joe Stump <joe@joestump.net> http://www.joestump.net "Label makers are proof God wants Sys Admins to be happy."

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- Joe Stump <joe@joestump.net> http://www.joestump.net "Label makers are proof God wants Sys Admins to be happy."

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- Joe Stump <joe@joestump.net> http://www.joestump.net "Label makers are proof God wants Sys Admins to be happy."