Re: dataobject

From: Date: Mon, 11 Oct 2004 13:22:44 +0000
Subject: Re: dataobject
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-33772@lists.php.net to get a copy of this message
Alan Knowles wrote:
Anyways here are a few notes I made along the way: - numrows is expensive in combination with unbuffered queries
interesting.. - I wonder if that affects libgda as well.
what do you mean? anyways MDB2 supports unbuffered queries and obviously numrows is going to be expensive when used with unbuffered queries. or do you mean if libgda even supports unbuffered queries?
- use MDB2 quote method for all datatypes (only use type constants internally - they seem very useful for complex types like "email" and should probably be integrated into MDB2 itself for internal use)
I'm not sure about the value of MDB datatypes - MDB1's types where far too over abstracted, I havent looked at MDB2's - I guess they have improved a bit.. (the problems where approaching the abstractions from a generics->db angle as apposed to a db->generics.
The main point about datatypes in MDB2 is that you can add your own very easily. Just like I did in my framework with a serialize datatype. So essentially people can do whatever they want.
- use MDB2::singleton and db_index to manage MDB2 objects
I removed all the singleton methods early on in DB_DataObject (and replaced with private globals), as they appeared to be one of the performance killers
Hmm anyways MDB2 manages an array of all instances inside a global array, so you can reference each instance by the array key. The singleton is indeed a bit expensive if you have a lot of instances, since it checks the dsn (not the options though).
- use MDB2 internal debugging capabilities - can we model raiseError after MDB2's raiseError()
Not seen it - what does it do differently?
hmm nevermind .. actually I think I will change it in MDB2 back again. Essentially MDB2 currently doesnt have an error class. However that seems to be a bad idea thinking about it now, since it makes it impossible to figure out if an error was created by MDB2 or some other class. This sucks since then you dont know if your are using the proper error code constants etc.
- can we get rid of extends PEAR in MDB2 (loosing expect() error) by a custom raiseError()
? - can you expand on this?
Well currently MDB2 extends from PEAR just to be able to do expect(). You also seem to be using expect() inside DO. The problem is that this cannot be done statically. So the idea was to add my own expect() method and then adding the necessary code to raiseError, but I am not sure how that could even be achieved. There is also the option of using ErrorStack, but this seems to not solve the original problem: cutting down the code size needed.
- insert/update/delete should return affected rows
This would be a major BC break.. - I'd be tempted to introduce exceptions/or PEAR error returns if BC was going to be busted at the same time..
Actually let me rephrase that: MDB2 returns the affected rows for the above statements to be inline with pdo.
- use MDB2 manager (reverse) to read database infos
?? - the idea is good.. - see comment earlier about over abstraction...
What I want to do in MDB2 is the following: - have method to just get the information from the database - have mapping methods inside the datatype module to map these to portable datatypes. this should again allow anyone to mess with the datatype module to change things as they want.
- integrate xml schema format (possibly use a custom parser) - MDB2 emulates database for oracle with users - sequenceKey() seems overly complex
yes - it's BC ontop of BC ontop of BC.... - I should have gone down the path of - if it's definatly not the primary key / autoincrement / nextval, give up! There are issues here - mainly to do with taking advantage of native incrementing on various backends (eg. actually using nextval() and auto_increment.)
I think I mentioned this to you before and I already implemented this into MDB2_DataObject. MDB2 essentially supports the following: $id = $mdb2->getBeforeID('foo'); $query = 'INSERT INTO foo (id, bar) VALUES ('.$mdb2->quote($id, 'integer').', '.$mdb2->quote('xxx', 'text').')'; $mdb2->query($query); $id = $mdb2->getAfterID($id, 'foo');
- MDB2 has float type support
Well this was more in reference to your todo list. MDB2 also has support for Dates and LOB's (allthough LOB's will need a bit of a redesign .. maybe to use streams ..)
- MDB2 quote converts php null to sql NULL
this isnt a major issue... :) - but php null is totally unreliable... - so I never trusted it..
unreliable in what way?
- MDB2 has all the methods needed to create tables
I've not looked at MDB2's version, but MDB1 was pretty messy AFAIR- it created char(1), even if the DB supported booleans.
well that was due to the Metabase philisophie of supporting all supporting all rdbms version with a single driver. In MDB2 I have made it possible to have different module versions. So now I can have different versions loaded automagically depending on the rdbms server version to better make use of native functionality.
- MDB2 has replace() support
This is very kludgy with DataObjects (it's a hell of alot cleaner with dbdo)
kludgy? .. anyways MDB2 essentially does a delete+insert (which is inline with how it works in mysql as much as possible) and then sets the affected rows appropriate (although sqlite's implementation does it different than mysql).
At this point in time, the big question goes, should a new version of DB_DataObjects, that is there when dbdo is not available: a) support PHP5 only? b) use PDO? c) use some of the object overloading ideas in dbdo?
a) well I dont really see the benefit of php5 only (except for E_STRICT). with MDB2's flexibility in terms of wrapping result in arbitrary result sets you can support interfaces/iterators with no problem. Same with overloading. What doesnt work in php4 we cant fix obviously. So it goes. b) I was planning on supporting pdo via a separate set of drivers c) what do you mean? regards, Lukas

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