Re: intoducing dbobj

have you looked at DBDO? - in pecl cvs (using libgda as a backend) and here: http://www.akbkhome.com/svn/pecl/dbdo/ The new version uses PDO as the backend, both designes are based around the experience of developing DB_DataObjects, and documented here http://www.akbkhome.com/wiki.php/DBDO/index.html From the code below. - config you need to support multiple databases from that was the problem I ran into from using PHP's ini_set/ .ini files, It didnt allow you to easily specify random ini entries. eg. dbdo.connect.mydb = mysql://xyz:abc@abcd/hhhh - factory rather than constructors Using factory, rather than constructors to do the object creation has proved over a long period the best way to go, as it allows you to autoload the implementation. - Autoquery the table structure Rather than specifying the keys/table structure etc. it's quite easy to query the structure on each call (and offer the ability to load it / cache it later..) - this makes the codeing time considably shorter. - you seem to be running change queries on the constructor and destrucotr, this seems a little counter intuative, alot of magic, (let alone risky as predicting the destructor in PHP can be a bit haphazard). That said, I've not had alot of time recently to work on the revamped and would be interested to see how you are getting on. Regards Alan Adamx wrote:

Hi, First i want to show you what I've been doing in the last months. I'm developing a php extension (that someday may became part of PECL). I call it dbobj, and is a high-performance object/relational persistence layer. As for now, it works only with postgreSQL, but I plan support for other DBMSs. Let's see a simple example how it works: <?php ini_set('dbobj.connStr','user=netigdev password=*** host=localhost'); ini_set('dbobj.case_sensitive',true); class autoIDtest extends dbobj { static $dbobj_config = array('table'=>'autoIDtestTable',

       'dbProps'=>array(
            //these are fields in the table
           'id'=>array('dbField'=>'id','type'=>'S','PK'=>true),   //type S means Serial/Sequence
           't'=>array('dbField'=>'textField','type'=>'T'),   //type T = Text
       ),
       'objProps'=>array(
            //these fields will be accessible from PHP code
           'id'=>array('sources'=>array('id'),'type'=>'i','access'=>'pub'),
           't'=>array('sources'=>'t','type'=>'S','access'=>'pub'),
       )

); } $idtest = new autoIDtest(); //no PKs given, so this will be a new object (we can give PKs, then it'll load a record) var_dump($idtest->id); $idtest->t = "id: {$idtest->id}"; ?> Two sql queries are executed during this script: 1: SELECT nextval('"autoIDtestTable_id_seq'");

      executed by $idtest = new autoIDtest();

2: INSERT INTO "autoIDtestTable"("id","alma")VALUES($1,$2);

      executed by the destructor of $idtest

nice, isn't it? Second, comes why i'm really writing to this list. This whole thing worths nothing if it isn't capable of handling connections between tables. Internally this will be done by defining an objProp of type relation. My problem is that i don't now what format in the dbobj_config to use. I'm thinking of something like this:

               'parent'=>array('sources'=>'parent','type'=>'>relatedClass','access'=>'pub') 
This means that parent is FK in the current table and the only PK field of relatedClass will be connected to it. This will cause an error if relatedClass doesn't have exactly one PK.

I'd be glad to see any ideas for this problem, or suggestions for dbobj! Thanks for reading my longer-than-it-should-be post, however I hope I was clear, if not, please ask! Adam Bankó