RE: [PEAR-DEV] RE: [PEAR-CVS] cvs: pear /DB/DB common.php

> -----Original Message----- > From: Stig S. Bakken [mailto:ssb@fast.no] > Sent: Monday, February 10, 2003 9:30 PM > To: Lukas Smith > Cc: pear-dev@lists.php.net > Subject: Re: [PEAR-DEV] RE: [PEAR-CVS] cvs: pear /DB/DB common.php > > On Sat, 8 Feb 2003, Lukas Smith wrote: > > > > -----Original Message----- > > > From: Stig Bakken [mailto:ssb@fast.no] > > > Sent: Saturday, February 08, 2003 8:14 AM > > > > > ssb Sat Feb 8 02:14:21 2003 EDT > > > > > > Modified files: > > > /pear/DB/DB common.php > > > Log: > > > * add support for params in limitQuery(), thanks to > > aangenieux@clever- > > > age.com > > > > Puh, now I am a little unsure about all of this. > > MDB's query() does not support params, since MDB has the prepareQuery() > > method for that. Nor do I understand this heavy use of prepared queries > > in PEAR DB. Correct me of I am wrong but the point of prepared queries > > is to speed up querying when the same query is used multiple times just > > with different data, if the database supports this feature. > > That, not having to think about quoting, and general cleanlyness and ease > of use. Ah here we start running into problems. MDB currently only supports '?' due to its Metabase heritage. The different placeholders as PEAR DB has them have the problem of not covering all the possible datatypes. I need to familiarize myself more with how prepare is implemented in the different RDBMS API's so that I can come up with a good proposal. Someone also mailed be today with a feature request making it possible to "name" the placeholders. While I am still mainly focused in extending the amount of drivers, this seems like a serious issue to consider. > > It seems PEAR DB uses it mostly to make it possible to pass the data in > > an array. Isn't that a job that would better be handled by a query > > builder? > > A query builder is an entirely different thing, with yet another level of > overhead. Params are just a way of doing portable binds/placeholders. Of course. The question is just where do you Stop? PEAR DB has the autoexecute stuff as well. This I think is certainly too much for a db abstraction layer. And this using of binds/placeholder is too imho. > > I guess my main question is if I should bother to add these features to > > the core of MDB or keep it in the pear wrapper. > > > > FYI: Another thing to note is that MDB has the setSelectedRowRange() > > method which will set the limit for the next query(). Regardless what > > querying method is used. > > Ease of use was one of the primary goals in the design of DB's API. > Things that can be done nicely as one-liners, should be available as > one-liners. IMHO this type of functionality should also be in the core of > MDB. The more stuff that goes in the wrapper, the more work DB 2.0 will > be. Obviously the API should be easy to use and allow a minimal amount of code. I just think that we are going over what the core abstraction package should be doing. If you need this level of ease of use it sounds to me like you are willing to give performance and are therefore willing to use a query builder (to me this is just a very limited query builder). Also this "abuse" of prepare/bind does not fit well into the system of having more then 3 datatypes (quoted, LOBs and unquoted). So lets think about what you are trying to do here ... The way I understand it you want to be able to do two things: 1. pass the "data" in the sql query as an array 2. quickly specify the "types" of the values (where PEAR DB only has the three types as I said above) 2. is sort of problematic in MDB. 1. is possible through the replace emulation .. which also calls a delete and is of course only meant for replacing data and not selecting ... so this is not the answer either. But it does give people the possibility to pass the data as an array (however it needs to be a multidimensional array) for inserts (unfortunately not update). You could argue that replace() is a query builder as well. I do have the get methods in MDB, mainly since they don't affect any of the other methods. So I am hesitant to add this to query(). I can of course add the code to limitQuery(). However I don't really see the point there in terms of lines of code. Obviously limitQuery is used when selecting data. So after limitQuery you will need to fetch anyways. Making it a two-liner atleast. So you might as well do: $mdb->setSelectedRowRange(); $mdb->get*(); So we have a solution for insert and select .. but not for update. On a related note: This was one of the reasons why I was hoping that people actually take a look at MDB's API this summer. I have repeatedly pointed out the differences, but received no feedback on this at all :-( It is sort of depressing to see things being added/changed in PEAR DB without any direct feedback chain to me. And it also seems that even though MDB was supposed to someday become the "standard" db abstraction layer of PEAR nobody seems interested in a discussion how the API should look like. We do have the opportunity to clean up a few minor things but more importantly we need to consider that MDB does add features that might make certain changes a good idea. Also remember that PEAR now has 2 very capable query builders, which was not the case when PEAR DB was originally designed. If this is not the case anymore, that is that MDB will not become the standard abstraction layer of PEAR (which would be unfortunate but not a biggy), I would like to know. Because then I could safe me a lot of work and rather start focusing on an MDB user community and not on trying to still please the PEAR DB community. Regards, Lukas