Re: PATCH: Multiple INI files for DB_DataObject

Matt Scifo wrote:

This sounds like it will work. Is this implementation in cvs yet? All except the factory stuff.

Regards Alan

On Wed, 2004-03-31 at 18:18, Alan Knowles wrote:

Matt Scifo wrote:

Alan This won't allow me to access project2's schema from a class using project1 though. The whole point is that ini_project1/database_project1 is in one file for application_a and ini_project2/database_project2 is in a completely different file for application_b. Even if I manually added the ini files using databaseStructure(), it wouldn't solve the problem of having two tablenames named the same in different oracle schemas.

This is something I have been working towards - eg. using 2 folders, one for each project. MyProject1/DataObjects/* .. with classes MyProject1_DataObjects_* MyProject2/DataObjects/* .. with classes MyProject2_DataObjects_* It is possible using seperate create.ini's to make these, however, the current factory method would not load these.. (and there is no support for require_path/class_location to have seperate folders) ** the long term idea is to support ::factory("{projectname}/{table}"); if you do use it this way, it is possible to access the schema for the other table: inside project1 require_once 'Project2/DataObjects/Sometable.php'; $do = new Project2_DataObjects_Sometable; $do->table(); // would load the correct schema (assuming you have used the ini_project2 stuff below. Regards Alan

Would it be beneficial to you if I provided a more detail description of what I am trying to do? I was hoping the first explanation was simple enough. Thanks -Matt Scifo On Wed, 2004-03-31 at 17:39, Alan Knowles wrote:

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