Re: MDB2 and Data Type Abstraction

Alan Knowles wrote:

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

Ok, sounds good.

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.

Well, lengths of text fields might be nice but not required. I suppose I havent really looked at the types for a bit...I've been working on non DB_DO projects. My main concern has to do with DB_DO and MDB conflicting on types. I'd like very much to see the types and such in MDB's XML representation being used (and stored for runtime use) in MDB_DO. Perhaps a little type checking (although MDB may do that...unclear on that right now) and let MDB do the translation. All it really takes is passing the right types in and creating the correct queries. We'll still hace to call quoteIdentifier (I can't tell you how great it is that that change got into MDB :-), but we shouldn't need quote or quoteSmart any more as MDB should know when to use it.

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.

Basically, I'm worried that MDB_DO will be a port instead of an overhaul. A lot of stuff in DB_DO is unnecesary or need to be changed in light of MDB...

Regards Alan