Re: Re: PATCH: Multiple INI files for DB_DataObject

Ok, I understand that and it makes sense. There are really two schools of thought for that. One is to code into the configuration of each module the loading of the specific ini files it needs. This works as long as you remember to do it for each module the right way. If you have a seperate DataObjects.ini file for each module,the ini file that looks like this: [DB_DataObject] database = mysql://user:pass@localhost/db schema_location = /path/to/DataObjects class_location = /path/to/DataObjects require_prefix = DataObjects/

class_prefix    = DataObjects_

Then for each module you could set the ini_file_n settings in THIS ini file for each module so that it has the tables it needs. This is the same way as above, only it loads the files for you from the configuration instead of from the code. It's only a slight difference, and would only useful to add to DataObject if lots of people wanted it. I definately thinnk that the append function you wrote should be included for the situations you're talking about. Joe Stump wrote:

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