Re: PATCH: Multiple INI files for DB_DataObject

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