Re: Fwd: [PEAR] Some tweaks to DB_DataObject

From: Date: Fri, 22 Apr 2005 15:03:09 +0000
Subject: Re: Fwd: [PEAR] Some tweaks to DB_DataObject
References: 1 2 3 4  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-37340@lists.php.net to get a copy of this message
Dan Rossi wrote:
No thats plenty info for me, I just need to work out the proccesses for doing so. Sorry guys, I've just had to jump and do them, while working on the projects and yes fast rate because I need to port one app to my newer code in a php5 envrionment then also model a smilar app off this next week, hence if I have run into troubles I've had to hack away at it :) May I ask where is the future for the DataObject going, it will be DBDO with similar methods ?
That ones a bit up in the air.. - I'm not that keen to use PDO's PHP api, as feels alot like pulling teeth..
Will DBDO also incorporate PDO ?
I started hacking on DBDO for PDO (the internal C API isnt as bad as the PHP API), but one of the projects I'm working on needed DBDO to work quickly so fixing all the bugs in the libgda version was quicker to deliver. I might sit down next week and have another play with it, as the the essential parts of the subversion extension are now done. Regards Alan
I tried to get PDO going on osx (I know i know non standard) this arvo it didnt want to load :) On 22/04/2005, at 11:45 PM, Lukas Smith wrote:
pear@electroteque.org wrote:
fixed that your diff would removed. b) try and make one change at a time, and make a diff for it.
Sorry please dont tell me to RTFM, i am not good with diffing or merging, thanks for showing me how to diff from cvs, but how to i merge into my current version ? I use eclipse, it has some merge features ?
basically the idea here is that you take the changes from your current diff. and then apply the changes to make each single feature/change you have separately to the current CVS version. You then safe the new diff in a separate file for each single feature/change. This will enable Alan to quickly go through your diffs so that he can look on a case by case basis at the implications of the diff to decide if it should be included or not. The problem is that you keep adding new changes at a fast rate that is hard to follow. As in was this change necessary for this or for that feature? I know this is going to be alot of work for you now. But its really a good habit to learn and is the only manageable way for people to look at your changes that only you know intimately. regards, Lukas


« previous php.pear.dev (#37340) next »