Re: PATCH: Multiple INI files for DB_DataObject

This sounds like it will work. Is this implementation in cvs yet? 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 > >>> > >>> > > >