Re: Re: PATCH: Multiple INI files for DB_DataObject

> 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� >>>>\P@�Y�%��<�). >>>>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."