Re: dataobject

Alan Knowles wrote:

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

hmm well if they dont they certainly need to add it. buffered queries only really fit the webworld .. not the desktop world.

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

ah you mean having to call the singleton method on every call to the database?

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

I definately agree that exceptions are nice as long as they dont leak out. When they leak out they seem too pushy imho to maintain rapid prototyping, which was why I started pondering a disable exception stuff etc .. which makes everything unclean again I guess :-)

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

Well pdo has nothing in that area atm and yes I am beginning to agree more and more that libgda would be a good starting place for pdo.

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

what do you mean? the purpose of the solution is to get back to using the native features instead of making everything fit the lowest common denominator ...

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

well you dont need to use getBeforeID() nor do you need to use getAfterId(). you can use sequences, emulated sequences, autoincrement directly as well.

- 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

yeah ... I hear you

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

which is fine by me .. if the above stuff is true then its simply inconsistent. but for the sake of not having to silence stuff with @ it would be nice to be able to easily determine if you have null values in an array without having to resort to array_keys().

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

yeah .. I noticed that in alot of places where I first used replace() it was actually removed over time because I discovered there would be a nice way to handle the situation.

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

Ok again I agree 100% that using exceptions internally would be nice. It shouldnt be a problem for users to be calling things using __get .. etc. Or are you also missing it for internal use?

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

Yes and no. PDO doesnt do alot of the portability things. It just handles the API side .. not the sql side of things. So it doesnt do datatypes, it doesnt do all the management things etc. That was never the plan. regards, Lukas