Re: Re: PATCH: Multiple INI files for DB_DataObject

> 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."