Re: dataobject

Comments inline.. Lukas Smith wrote:

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?

I was wondering if libgda was slower with numrows / and how it handled unbuffered queries, rodrigo (libgda/ maintainer) is very open to ideas - so it may be worth investigating..

- 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).

basically if you need to call a method on each fetch(), rather than just pulling a global, the profiling I did seemed to indicate a big difference, mind you, reading those profile data reports was never very simple..

- 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.

DataObjects only uses the expect in one location (checking for numrows supported on update()) - I'm getting very itchy to start using PHP5 exceptions, as they look cleaner every time I debug code that ignored an error.. :)

- 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.

This is quite an interesting area - from what I've seen of libgda, it's probably the best/smartest implementation I've seen yet of this. - PDO seems to be re-inventing the wheel a bit here.. (actually it's one of the annoying things about PDO in general - it looks like it's trying to re-invent libgda, and is 3 years behind.. )

- 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.)

- integrate xml schema format (possibly use a custom parser) 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');

at this point it looks like mdb suffers from the same problem that I worked around on DB, - it has stopped using autoincrement/nextval etc. - and affects all other appliations that manipulate the same database, (eg. desktop apps etc.)

$query = 'INSERT INTO foo (id, bar) VALUES ('.$mdb2->quote($id, 'integer').', '.$mdb2->quote('xxx', 'text').')'; $mdb2->query($query); $id = $mdb2->getAfterID($id, 'foo'); goes back to the classic problem, that while autoinc/nextval are not portable, 98% of apps developed make use of the single API, rather than the real portability aspect.. (not saying that abstracting that shouldnt be possible, but it probably should not be the default behaviour)

- MDB2 has float type support

Well this was more in reference to your todo list.

yeah - this was supposed to do full type checking (eg. write 0.00 rather than 0 for floats), libgda did alot of that work for me in dbdo - Although I did need to write a toSQL type method for types.

MDB2 also has support for Dates and LOB's (allthough LOB's will need a bit of a redesign .. maybe to use streams ..)

I had a bit of fun today looking at Date_Span (it screams at you - why not re-write this to only accept Date Objects..) - I guess ideally pierre's date extension should be be used as the default date type returned by date type columns.

- 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? var $someval;

is_null($this->someval) => true ! isset($this->someval) => false ! $this->someval = null; is_null($this->someval) => true ! isset($this->someval) => false ! unset($this->someval); is_null($this->someval) => true ! isset($this->someval) => false ! ** some of this may/maynot work.. - but it was just a little unpredicatable I spent ages trying to use nulls and just gave up in the end - there was a thread on internals@ about this - basically from what I remember Andi doesnt regard nulls as a constant, more as a indicator of not set.. AFAIR it's probably feasible to check in dbdo.. - as we store the results in a seperate area from the object var's (and merge them at __get/print_r() time)

- MDB2 has replace() support

This is very kludgy with DataObjects (it's a hell of alot cleaner with dbdo)

kludgy?

yeah it's done by checking the value of primary ID - but it's not 100% reliable (eg. if the end user manually sets ID for some reason - it assumes it's an update..)

.. 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).

I always thought it was getting too clever, I have needed replace, but it's < 5% of the time.. - so by implementing in those specific locations, The likely behaviour is generally a little more predicatable.., rather than depending on some magical behaviour, that may not do as expected...

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.

exceptions and more especially overload __get .. (although AFAIR, __get_properties is not implemented so print_r() is borked = which is why dbdo is soooo cool :)

b) I was planning on supporting pdo via a separate set of drivers

PDO seems to infer that MDB is less necessary, although see above about my general concerns on PDO..

c) what do you mean?

in dbdo $obj->fetch() doesnt actually call fetch (it just flags the object as using rowX $obj->xxx = 1 is stored in the object properties echo $obj->xxx checks a) if you;ve set the object property, if not it returns the row data for column xxx (hence is alot faster than classic dataobjects) updates / inserts actually know what you've changed.. - so they are far more efficient.. I'm not sure all the dbdo stuff is even feasible in raw PHP.. - even if it was, I'm sure it would be even more kludgy than the current global result/connection cache in DataObjects at present. Regards Alan

regards, Lukas