Re: MDB2 and Data Type Abstraction

[comments in line..]

As for MDB_DataObject, I wonder how that's going to work....DB_DO has its own format for storing types and such, based on what came from reverse engineering DB types. This obviously won't fly with MDB as it has its own types. So I assume that it will use MDB's types...

I'm hoping the intention is that we start with DB_DO's curent types (adding if necessary - as floats, and the size of fields is not curently handled).. - then feed back the requirements into MDB.

which again begs the question of where this will be stored as it's already in the XML anyway. Sorry to those who are working on it, I'm sure you're thinking of all of these things.

I think the general consensus is that storing the schema in a php array at the somewhere in the class file (maybe even in a static class property in PHP5 compatibility mode?) - this schema being the smallest, most effecient representation of the class required for building the SQL.

Basically it comes down to this. I like PEAR. I've thrown in my lot with PEAR and like all of its features. However, there is no really good solution for this DB_DO problem. While DB_DO is pretty good, it's not only HUGE,

yeah - everytime I look at the file line number it scare me too :)

it doesn't do as many datatypes as would be nice

other than floats, (and perhaps numerics) had you any specifics in mind.

and it has to deal with backend specific issues outside of DB, which makes things very confusing and hard to follow.

Yeah - autoincrement (and the native sequences) should be supported 'in some way' by DB/MDB really. - there is so much crap in dataobjects that deals with that, that should be pushed to a backend really. Regards Alan -- Can you help out? Need Consulting Services or Know of a Job? http://www.akbkhome.com