Re: [DB] returning typed data when fetching rows

Guillaume Cocatre-Zilgien wrote:

Paul M Jones wrote:

Guillaume, do you think an add-on to DB_Table would be useful in this case? If so, write up a patch and we can work on incorporating it.

Well, that's my problem: I'm still a bit lost, with all those different implementations. Once I know what which class should be patched, I will have no problem writing a patch that integrates well.

DB_Table and DB_DataObjects know the types cause they work on a higher abstraction level. Basically instead of having to pass the types manually inside all queries you need to do it only once. Using the MDB[2]_Manager something like that is easily possible as well. You can define your schema in xml and then parse the file. YOu may want to serialize the xml into a format that can be parsed more quickly. Now the trick is to reorganize the array to just contain the relevant types for each query. Again DB_Table and DB_DatabObjects dont run into this problem cause they build the SQL for you. In MDB[2] you would have to use tableInfo() to get the columns in question. And it should also be possible to plugin some kind of caching there. So if you want to hand code your SQL you are probably best of extending MDB[2]. Otherwise DB_Table and DB_DataObject will probably provide the easier route to success .. especially since an equivalent thing hasnt been written based on MDB[2].

But I must agree with regard to supporting the "array" data type; I don't think the PEAR abstraction libraries can reasonably be expected to handle them all. E.g., I think PG has a "geo" data type for latitude/longitude coordinates; in the same manner MySQL has its own special types (enum, set).

Why not? So if I need to use even just one proprietary feature, why do I have to hack it myself? Isn't PEAR about making developers' job easier by providing high quality code?

I believe that proprietary features should be supported by abstraction layers, provided that the developer is informed that it is, in fact, proprietary, and that this particular portion of code won't be easily portable. I don't expect it from a 1.0 version, but DB and the likes are already quite mature now, aren't they?

This is exactly what I tried to do with MDB2. I have worked hard to make MDB2 extensible. I have also added a module where I have added method for features that cannot be abstracted across all RDBMS. However for this particular feature it seems to me like extending the datatype module is the way to go. Anyways sorry for smartassing you on my initial post. Its just that everybody rather extends upon DB to bloat it even further, instead of taking a look at the package build to make this kind of thing possible without ending up with a bloat package. So again please accept my apologies ... regards, Lukas