Re: Re: PATCH: Multiple INI files for DB_DataObject

> Maybe you could explain why your system is this way? Sure ... I have a two tier application as such: Tier 1: Core Framework (users, content mgmt., groups, etc.) Tier 2: Modules (faq, blog, etc.) Modules are *completely* autonomous. All they need to work is the core framework. I have DataObjects for the core framework that are often used by Tier 2 modules. Modules have their own DataObjects each in their own directories. I don't want to put every single table in a main INI file because not every single table exists on every single setup of my framework (ie. one customer has blogs for news management, but not faq, while another has both). Now I could reproduce definitions for the core tables in *each* of my modules, but that's redundant and requires me to rebuild INI files everytime I change my core table structure (not often, but still ...). What I've posted worked for me. When my core framework loads up I load up the core INI files along with INI files for the modules currently installed on the system (this way modules can interface with other modules via DataObjects if need be). When I go to access my DataObject from a module I know that all of my other DataObjects are there (the core ones that I know I need - extra ones can be loaded if need be manually). --Joe > > 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." > > -- > 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."