[PHP-DB] Re: Common DB Abstraction Layer:
Hello, "Tomas V.V.Cox" wrote: > > Manuel Lemos wrote: > > > > Hello, > > > > John Lim wrote: > > > Each designer has a different point of view, like Tomas has > > > written a really excellent oci8 "select limit" emulation, but looking > > > at the code, it's so complicated that i decided not to incorporate it > > > in ADODB because I value simplicity. I know Tomas' code works > > > in theory, and its really impressive that you even considered UNIONs, > > > Tomas, but I just like "simple" code that I can keep in my head. > > > > But it does not work with computed columns like those that apply > > functions (COUNT, SUM, SUBSTRING, etc...). The code assumes that you are > > actually selecting only real table fields. I think it also does not work > > with columns with table name prefixes. > > That's partially true. But it's a common practise to use column aliases > in conyunction with functions (and a must for assoc fetchs) and this is > supported by the code I wrote, for ex: > > select count(field) as count from foo; That would work, but you require people to change their queries. I guess that does not work as general practice because. > Also if Oracle name a sum(foo) column as "sum" will be trivial to add > it. > > Any way I said it later, a real SQL parser will be the solution. Stig > came with the idea time ago and nowadays it will help a lot in many > other cases. I think that for Oracle there is a better solution that does not require Oracle to fully run queries that may return millions of rows, when you just want to return the first. That solution is to use server side cursors. Regards, Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase
John, in addition to the list you posted, there's - inconsistent/incomplete metadata support. it would be nice, for example if the MySQL extension would be more precise about a field type than "string", etc i tried hard and failed to describe why i'd want to start a C based DB library, and you have described the issues better than ive done in the past weeks. im less particular on how things look at the PHP level (though i have definite preferences), than to provide a general framework in C for user-level code to build on. there are lots of issues not addressed or handled in an ad-hoc way in the database extensions that have to be addressed at a lower level, and doing so presents unique opportunities to other module writers who need DB support in their extensions. i'll leave web developers to fight over flavors of ice-cream - i'm happy to churn the milk. l0t3k BTW - i think i'll start using the term Unified API. seems Rorschach (sp?) enough to please most folk. John Lim <[EMAIL PROTECTED]> wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > Actually the common code is already available: it is the > database extension API's. But most of the problems are > in the database extension APIs also, and our work is fixing > their mistakes. > > Examples: > -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase, > when everyone else is using lowercase. > > -Magic Quotes murders our quoting, and what about magic quotes > sybase which happens to be for interbase and sql server too! > > -Postgresql does not have an error number to return. And there is > no pg_insert_id() either. > > -Interbase's API is missing an arm and a leg, and whether it is > the left or right arm missing is not documented anywhere. > > -All extensions should support blobs like Oracle, with a fetch mode > that makes "SELECT blob FROM table" transparent with no special > coding. > > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... > > John -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase
On Wed, 21 Nov 2001 16:14:04 +0100 (MET) Luc Saint-Elie <[EMAIL PROTECTED]> wrote: > En réponse à Pierre-Alain Joye <[EMAIL PROTECTED]>: > > > > This definition defines more a common interface to connect to a db, > > execute queries, fetch the result and eventually gives errors reports > > ;). > > Somehow yes (do I still win the $15,000 ???) :) christmast time soon... ;) > I don't exactly agree. > Of course most web developments with php use mySQL (or similar BD) so the > porting is a very light issue > Of course, enterprise development (intranet, portals..) use other BD.. but the > porting is still a very light issue except if you company change very often its > licensing policy switching vendors back and forth ;- ) > So may be for your specific enterprise IT environment PEAR::BD right now > doesn't fit your needs.. fine.. some day hope this will change, but its more > a "do you support DB XX ?" issue than a "are you cross DB ?" one. If you develop a complete application (a KMS by example), you will like to create a standart version that you don't have to customize. Customer A uses Oracle, B uses Sybase and C uses SQLserver, the best way for the connectivity part is real abstraction layer whatever you use for the application itself. You don't have to create new queries, stored procs and so on, every times you ve got a new rdmbs to work with. For your internal application needs, effectivly you will not change BD every day, and as far you respect SQL standarts, it's not a great jobs to move. > The result is that the question (IMHO) is more a "is it possible to adapt > PEAR::DB to my specific case ?" (been at risk that the answer is "no") > than "how could we start from the beginning to build something else?" The wheel ? ;) pa -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase
En réponse à Pierre-Alain Joye <[EMAIL PROTECTED]>: > This definition defines more a common interface to connect to a db, > execute queries, fetch the result and eventually gives errors reports > ;). Somehow yes (do I still win the $15,000 ???) > IMO, the need of a real abstraction layer is not a must for the majority > of php endusers. In another view, it will give to php tools for projects > who use actually others systems (MS asp, j2ee,...). > Most of pure web developments don't need a real abst. layer, intranet > portails or enterprise tools need. I don't exactly agree. Of course most web developments with php use mySQL (or similar BD) so the porting is a very light issue Of course, enterprise development (intranet, portals..) use other BD.. but the porting is still a very light issue except if you company change very often its licensing policy switching vendors back and forth ;- ) So may be for your specific enterprise IT environment PEAR::BD right now doesn't fit your needs.. fine.. some day hope this will change, but its more a "do you support DB XX ?" issue than a "are you cross DB ?" one. The result is that the question (IMHO) is more a "is it possible to adapt PEAR::DB to my specific case ?" (been at risk that the answer is "no") than "how could we start from the beginning to build something else?" Luc -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer:
Manuel Lemos wrote: > > Hello, > > John Lim wrote: > > Each designer has a different point of view, like Tomas has > > written a really excellent oci8 "select limit" emulation, but looking > > at the code, it's so complicated that i decided not to incorporate it > > in ADODB because I value simplicity. I know Tomas' code works > > in theory, and its really impressive that you even considered UNIONs, > > Tomas, but I just like "simple" code that I can keep in my head. > > But it does not work with computed columns like those that apply > functions (COUNT, SUM, SUBSTRING, etc...). The code assumes that you are > actually selecting only real table fields. I think it also does not work > with columns with table name prefixes. That's partially true. But it's a common practise to use column aliases in conyunction with functions (and a must for assoc fetchs) and this is supported by the code I wrote, for ex: select count(field) as count from foo; Also if Oracle name a sum(foo) column as "sum" will be trivial to add it. Any way I said it later, a real SQL parser will be the solution. Stig came with the idea time ago and nowadays it will help a lot in many other cases. Tomas V.V.Cox -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase
En réponse à Joao Prado Maia <[EMAIL PROTECTED]>:
> Now for the $15,000 question: does anyone else agree with this ? If
> PEAR::DB is not abstracting the database what is the purpose of such a
> library ?
Well I strongly need thoses $15 000 $ so
What is the purpose ?
As a "average php user/developper" I dont really care about the "pure cross
plateform/database issue" but I do care about a standard, clean, secure ("my-
bugs-free") and easy way to use a database, and PEAR::BD + Thomas V Cox
tutorial are under this aspect real time savers...
So the purpose is "ease my life"...
Well well discuss privately about money transfert
Luc
--
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer
John Lim wrote: Hi John, > > > > > The only exit I see of the multi abstraction layers problems is trying > > to join all those communities and start a new development from the > > ground. The code is almost all written so only need to glue it to meet > > the specs of the new resultant layer. Then each team could provide > > their own wrappers to make things easy to their users. That's IMO a > > cooperative behaviour. > > > > Tomas V.V.Cox > > Hi Tomas, Manuel, everyone, > > I think that different programmers have different needs. > Metabase's goal is 100% DB portability. PEAR DB builds on the > PEAR classes to give a solid set of classes. ADODB is aimed > at converting the heathen ASP'ers to the "one true religion". > I also know of a PHP DBI class also from people who still need > the $perl~= /fix/; All the things you say here could be the features of a new abstraction layer done by a high experimented team. The point is to relax a little our obsessions. > Each designer has a different point of view, like Tomas has > written a really excellent oci8 "select limit" emulation, but looking > at the code, it's so complicated that i decided not to incorporate it > in ADODB because I value simplicity. I know Tomas' code works > in theory, and its really impressive that you even considered UNIONs, > Tomas, but I just like "simple" code that I can keep in my head. Thanks for the kind words :-). I know it's a little bit obscure cause I needed to implement part of a SQL parser, but with more resources in a supposed union we could develop a real SQL parser and in the case of the row limit for Oracle the code needed will be reduced to two method calls. > I think some standardization in terms of API is good, but I don't > think most people care. Newcomers to programming will want to use > something easy and "standard" - is PEAR DB already the standard? > Windows programmers would want to use something familar. I already > have a prototype PEAR DB api wrapper for ADODB , and ADODB has > support for PEAR Error() also, but the people who like ADODB > generally are not that interested (at the moment). They don't want automatic error handling? Uff, I couldn't live with it ;) > > to join all those communities and start a new development from the > > ground. The code is almost all written so only need to glue it to meet > > the specs of the new resultant layer. > > Actually the common code is already available: it is the > database extension API's. But most of the problems are > in the database extension APIs also, and our work is fixing > their mistakes. > > Examples: > -Oracle ocifetchinto() returns OCI_ASSOC arrays in uppercase, > when everyone else is using lowercase. >From PEAR we requested the native C PHP function to change the case of the key of the resultant array and the waste of exec time is almost null. This function will be avaible in 4.1 (I guess) and in the PEAR DB that will come with it (I hope). > -Magic Quotes murders our quoting, and what about magic quotes > sybase which happens to be for interbase and sql server too! Yeah, magic_quotes_* are evil and they should be off by default. Anyone with enought karma can do that? :-P > -Postgresql does not have an error number to return. And there is > no pg_insert_id() either. The error numbers is a PHP API problem or Postgres API one? PHP would suck a lot if that is supported but not used, knowing that the Postgres guys change the error messages in each release. About the pg_insert_id(), Postgres have native support for sequences IMO the real way to do that kind of things. > -Interbase's API is missing an arm and a leg, and whether it is > the left or right arm missing is not documented anywhere. That's true. I used Interbase time ago and was very robust, also now is Open Source and is a backend with the features of Postgres and the speed of MySQL. The lack of a good PHP support is limiting it's use for sure. Well, a DB with some backdoors but they are being closed ;). > -All extensions should support blobs like Oracle, with a fetch mode > that makes "SELECT blob FROM table" transparent with no special > coding. I don't use them, can't say anything on that. > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... > That's solved (see above) :-) Tomas V.V.Cox -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: Common DB Abstraction Layer: Re: [PEAR-DEV] Adoption of Metabase
Hello, John Lim wrote: > Each designer has a different point of view, like Tomas has > written a really excellent oci8 "select limit" emulation, but looking > at the code, it's so complicated that i decided not to incorporate it > in ADODB because I value simplicity. I know Tomas' code works > in theory, and its really impressive that you even considered UNIONs, > Tomas, but I just like "simple" code that I can keep in my head. But it does not work with computed columns like those that apply functions (COUNT, SUM, SUBSTRING, etc...). The code assumes that you are actually selecting only real table fields. I think it also does not work with columns with table name prefixes. > I think some standardization in terms of API is good, but I don't > think most people care. Newcomers to programming will want to use > something easy and "standard" - is PEAR DB already the standard? Newcomers never know what they want. Most of them learn by copying examples without really understanding them right away. Once they evolve they start caring about things like: Oh, MySQL does not provide good support for transactions or sub-selects. I have to use something else like PostgreSQL, Oracle, MS SQL, whatever. Gee, but my code will not work seeminglessly with those databases! That would not be a problems if they were using Metabase, but they did not know that portability is important to protect their work from changes like this. This happens very often when you mature as a database programming developer. > If we fixed these problems and more, we could talk about having > a unified API. Otherwise for the Oracle OCI_ASSOC, I would prefer > not to change it for speed, Manuel would want to provide an emulation > layer, i would object because it's slow, etc... If you want to resort to non-portable database programming, just stick with the native database API that PHP offers and you will get all the speed that is possible. Using a database abstraction that does not offer portability and still adds execution overhead does not make much sense. Your programs still need to be adapted to run with different databases and they will still be slower than using the native PHP database APIs. > PS: the history of windows shows it's ok to have multiple abstraction > layers: ODBC, RDO, DAO, ADO, ADO+, JDBC, Delphi's db classes, VB's data > controls, provided there is progress. Most of them are either for different languages or just wrap around each other, so they are really not competing in the same language domain. Regards, Manuel Lemos -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
