Re: intoducing dbobj

Thanks for your mail, and the good questions! I've looked at DBDO and it is a very handy tool to manage your databases, but it has a more conventional concept of handling data than dbobj. What I'm writing is object persistence what is very different in philosophy compared to DBDO. Object persistence means a lot of magic, because it focuses on objects and classes, not on tables and records. Supporting multiple databases is crucial in some applications, so I plan to implement is, but it is not first priority. I'm going to implement this together with mysql and other dbms support. I'm not using PDO or any other db abstraction layer for two reasons: 1: I want really good performance 2: I want to use some dmbs's special features (eg. inheritence in posgreSQL's) and it makes abstraction layer useless if i use incompatible sql - factory rather than constructors I can autoload the implementation from the constructor. Better, the user can have a __autoload() function, so they can have any source layout. I like creating a new object (that will be inserted later) with 'new' operator. The problem is I don't now any better syntax for getting existing object from database: $t = dbobj::getObject('classname',array('id'=>15)); What i hate in this is passing className as string. Any ideas? - Autoquery the table structure You are perfectly right, it makes coding time shorter. I'm planning to implement it later, but it's not first priority at the moment. I think I'll write some PHP script to do the autoquery that generates xml configuration files for dbobj. This way the user can add more tweaking in the script itself, consider building a circle objProp, what is one field in postgreSQL, but three fields in mySQL To sum it up, the two most important features of dbobj are: 1: really object oriented (1 table = 1 class, 1 row = 1 object) 2: really high performance Dbobj is not for php first-timers, it is ment to be used with complex business logic, that may rely on higher OO 'features' (inheritence, encapsulation). //I'm not saying that DBDO is worse than 'my precious', only that DBDO is more close to the classical way of managing databases (what may suit people who got used to that concept) Do the list have any thoughts on my relation syntax?(like it/ don't like it/what should be changed)?

'parent'=>array('sources'=>'parent','type'=>'>relatedClass','access'=>'pub')

Adam Alan Knowles wrote:

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