RE: [PEAR] a slightly harder question

> -----Original Message----- > From: Justin Patrin [mailto:papercrane@gmail.com] > Sent: Friday, February 25, 2005 11:13 AM > To: Sasha Sklar > Cc: pear-general@lists.php.net > Subject: Re: [PEAR] a slightly harder question > > On Thu, 24 Feb 2005 17:57:40 -0800, Sasha Sklar > <Sasha.Sklar@craveonline.com> wrote: > > I've been working at this new job for about 4 days, and they've just > > dropped a doozy on me. > > > > All reads are performed on one database, and all writes are performed on > > another. The writes are then pushed to the read db by a server process. > > > > So basically, all operations performed with the get(), find(), fetch(), > > count(), etc go to DB1, and all uses of update(), delete(), insert(), > > etc go to DB2. > > > > So, I figure I can basically have two sets of identical DataObject > > classes, one for reading and one for writing. But I'm having trouble > > figuring out how to configure them. Or could I simply have the two > > databases in the config file, but can it handle db's with identical > > tables? > > > > I'm sorry that I keep coming to you guys, I'd much rather figure stuff > > out on my own, but I kinda got blindsided by this issue. Any suggestions > > are appreciated. > > > > You don't need 2 sets of DataObject classes. This would be a > nightmare. I use a *very* simple system for something similar (dev vs. > live DBs). I have one db.ini and db.links.ini file and symlink the > db2.ini and db2.links.ini files to them. Then I have 2 DataObject.ini > files, oone for each DB. The DOs don't care what DB they're on, you > just have to set your DSN correctly. > > And since you're using 2 DBs of the same name (I assume) you should > only need 2 DataObject.ini files with different hosts in the DSN. > > The problem you'd face with this is that you can connect to one *or* > the other. I really have no idea how you'd connect to 2 DBs with the > same DB name on different hosts with DB_DataObject in the same script. > > -- > Justin Patrin > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php This is what I've gotten to work: // Include these class definitions so the object will pass in sessions require_once '../DataObjectsRead/Test.php'; require_once '../DataObjectsWrite/Test.php'; $config = parse_ini_file('../DataObjectsRead/DataObjectsRead.ini',TRUE); foreach ($config as $class=>$values) { $options = &PEAR::getStaticProperty($class, 'options'); $options = $values; } $read_test = DB_DataObject::factory('test'); $config = parse_ini_file('../DataObjectsWrite/DataObjectsWrite.ini',TRUE); foreach ($config as $class=>$values) { $options = &PEAR::getStaticProperty($class, 'options'); $options = $values; } $write_test = DB_DataObject::factory('test'); If a more elegant way occurs to you, let me know. I'm going to use this until I've read through the source of DataObject and DB a few more times. Since I'm putting client classes in between my dataobjects and the scripts, I can always change it later.