Re: PATCH: Multiple INI files for DB_DataObject

I know this works in CVS:

ini_project1      = /path/to/project1/ini/file.ini

database_project1 = mysql://user:password@localhost/test

ini_project2      = /path/to/project2/ini/file.ini

database_project2 = oci://user:password@localhost/test when you run the generator with this - it should add var $database = 'project1'; to all the classes - to indicate which ini/dsn to use. Regards Alan Matt Scifo wrote:

I am using DataObject in my framework which uses oci8 as the backend db. My framework allows applications written using the framework to communicate with each other. For instance, adding a user to a CRM application would communicate with a Mailing List application and add the new user to the mailing list. In order for applications to be able to communicate, a communication link must be created which links an object in one application to an object in another application. Since each application is separate, the framework code that allows communication between applications must be abstract. Links are managed through the use of the DB_DataObject classes. However, the problem is that application A doesn't have the classes and schema info for application B loaded and therefore can't manage a link. The patch discussed in this post will allow me to load another application's schema into another application. I have concerns though about whether or not this will be sufficient for my needs because I am using Oracle as my backend db. Lets say I have a schema (oracle instance schema) called 'APPLICATION_A' and another called 'APPLICATION_B'. These are located in the 'MYDB' instance (equivalent to a database in other rdbms's). Each schema has a table called 'LOG', yet they contain different data. If I need to be able to manage links between APPLICATION_A.LOG and APPLICATION_B.LOG, I would call DB_DataObject::databaseStructure('MYDB', parse_ini_file('/apps/APPLICATION_B/MYDB.ini',true), parse_ini_file('/apps/APPLICATION_B/MYDB.link.ini',true)); from 'APPLICATION_A'. This would load the 'LOG' table from 'APPLICATION_B' into the schema config for 'APPLICATION_A'. The problem is 'APPLICATION_A' already has a 'LOG' table. So in this sense, DataObject has some issues dealing with Oracle database schemas. Is there any way to accomplish what I am trying to do? Any possible patches that could be applied to DataObject? -Matt Scifo Alan Knowles wrote:

Have a go with CVS now, - this should enable global assignment of database structure, even modifying it on the fly (in theory...) Regards Alan /**

     * Autoload or manually load the table definitions
     *
     *
     * usage :
     * DB_DataObject::databaseStructure(  'databasename',
     *                           parse_ini_file('mydb.ini',true),
     *                           parse_ini_file('mydb.link.ini',true));
     *
     * obviously you dont have to use ini files.. (just return array similar to ini files..)
     *
     * It should append to the table structure array
     * (eg. it doesnt overwrite data
     *
     * @param optional string  name of database to assign
     * @param optional array   structure of database, and keys
     * @param optional array  table links
     * @access public
     * @static
     * @return true
     */

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

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com

-- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com