Re: MDB2 and Data Type Abstraction

Lukas Smith wrote:

Justin Patrin wrote:

Basically, I was looking for some kind of automatic datatype abstraction. In other words, I've created an XML schema for my DB, which creates it for me. I like that. But now that I want to query, that all seems to go away. To get the types back correctly (date conversions, etc) I have to specify the types in the call...even though I already specified it for the table in the XML file.

I dont have a solution for that ATM.

Basically what I'm looking for is to specify a table, give an assoc array of values, and have my record inserted or updated. This is part of what DB_DataObject does, but I'm looking for something a bit simpler.

Actually as you have seen on the list people are working on an MDB_DataObject. This is how I envision we will be able to cover that request. And without generating the SQL its kinda hard to know what you are inserting into your queries are fetching from your result sets. So you really need something like DB_DO for this kind of stuff (I think?).

Another question as well, as I'll probably have to implement some of this myself. Is there any way to tell MDB to read in the XML file into a useful format in PHP that I could use? (Akin to DB_DataObject's config array.)

Using the Manager you can read in an array representation of the schema file. Check out the example.php file in the docs/examples/ directory. At the very bottom I show how that can be done (in this case I load the schema via the reverse engineering code, but if you load the schema from an existing xml file it works just as well).

Well.....it seems to me (and this is just my opinion, but...) the schema for MDB is pretty much useless. Sure, it makes putting the DB on multiple backends easier, but it doesn't do anything in the actual usage of the DB. Manually setting all of those types would be a major pain. 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...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. 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, it doesn't do as many datatypes as would be nice and it has to deal with backend specific issues outside of DB, which makes things very confusing and hard to follow. Don't get me wrong, I like using it, but I'd like to use the better features of MDB. MDB is nice, but it's only half a solution. It needs another layer, yet to be written, to support *easy* datatype abstraction. This makes switching to it very hard as everything has to be done over from the ground up. I just found and read about Propel last night. That's a nice solution. It seems to support everything that MDB and an MDB_DataObject would do. However, it's not based on PEAR. Like I said, I like staying in PEAR. It's also PHP5 only, which makes means that it's not nearly ready to use in production. So herein is the dilemma. Wait for PEAR to catch up (and try to help in the process), which will take a fair amount of time and lots of work; or use an outside system which is already done and completely working, but still can't be used in production at least until PHP5 is stablle, likely longer for *real* production. I honestly don't now where to go now. -- paperCrane <Justin Patrin>