Re: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]
Hello Mark, On 31-Jan-01 16:33:56, you wrote: I have been crafting my own database abstraction layer, and in doing so create an array of the results of a query. Is this an db abstraction layer written in php (script), or written as a module for php (C)? I was thinking of writing an (open source) db-abstraction module (that uses existing db-modules, of course), which could then be used from php-script as well as from other modules that need db-functionality without committing to a specific database. Or, does such a module exist already and should I concentrate on using and/or co-developing that one? I'd be open to turning it into C, as all my layer is really doing at its core is to do every single bit of error checking and API utilization for all the different DB drivers present on the system. Before trying to re-invent the wheel, maybe you would like to take a look at Metabase. It is not yet written in C, but nothing stops it from being converted. Unlike others it assures inter-database application portability. What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly see the point of using objects to do the work that a general function would do just as well and without any need to instantiate it. Objects are important to interface with different database drivers using the same API, but yes for the public API objects are not needed, they are really confusing for less experienced programmers and they are also a problem for PHP3 users (yes, a lot of PHP developer can't or don't want to move to PHP 4). I need to spend some time with the Zend API to see if it's really worth it for my time to go about doing it, but yes, I am very much considering turning it into C. I doubt that it is worthy, not just because of the conversion risks but also the maintenance costs. Instead, if you would like to join and contribute of Metabase, look here for this poll and tell how would you like to participate. http://www.egroups.co.uk/surveys/metabase-dev?id=392814 Metabase is available for free and over 4.000 unique PHP users downloaded it from here: http://phpclasses.UpperDesign.com/browse.html/package/20 There are several ready to use components based on Metabase like this for browsing query results: http://phpclasses.UpperDesign.com/browse.html/package/130 or even full application frameworks like Binary Cloud: http://www.binarycloud.com/ Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development 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-DEV] database abstraction layers [from: MySQLfeature/bug]
This is something that PHP has always lacked. Its also something that I have always found to be the most attractive about application servers like Allaire's Cold Fusion (http://www.allaire.com/). The ability to totally abstract database access makes it much easier on the developer and transparent to the end-user. While I agree that there are high maintenance costs, I still believe that its worth it in this case. For an initial offering, a subset of DB functionailty would be needed, something that all of the databases offer, for example: 1) $connection_id = db_connect( $host_string ); 2) $query_result = db_query( $query ); 3) $query_row = db_fetch_row( $query_result ); 4) void db_close( $connection_id ); (Perhaps $host_string is the identifier for some defined datasource in the php.ini or .htaccess files) This abstraction (any abstraction for that matter) would open up the doors for quite a number of interesting capabailities. For example, a flatfile "driver" that would be queried, or a google "driver." PEAR is fine for most people (myself included) but from an efficiency standpoint, this would be much better handled from the PHP API level, and not from the PHP language level. In any case, I am more than willing to help out in any way that I can. Regards, === Sean Bright [EMAIL PROTECTED] / [EMAIL PROTECTED] / http://www.seanbright.com/ === -Original Message- From: Manuel Lemos [mailto:[EMAIL PROTECTED]] Sent: Sunday, February 04, 2001 2:12 PM To: [EMAIL PROTECTED] Subject: Re: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug] Hello Mark, On 31-Jan-01 16:33:56, you wrote: I have been crafting my own database abstraction layer, and in doing so create an array of the results of a query. Is this an db abstraction layer written in php (script), or written as a module for php (C)? I was thinking of writing an (open source) db-abstraction module (that uses existing db-modules, of course), which could then be used from php-script as well as from other modules that need db-functionality without committing to a specific database. Or, does such a module exist already and should I concentrate on using and/or co-developing that one? I'd be open to turning it into C, as all my layer is really doing at its core is to do every single bit of error checking and API utilization for all the different DB drivers present on the system. Before trying to re-invent the wheel, maybe you would like to take a look at Metabase. It is not yet written in C, but nothing stops it from being converted. Unlike others it assures inter-database application portability. What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly see the point of using objects to do the work that a general function would do just as well and without any need to instantiate it. Objects are important to interface with different database drivers using the same API, but yes for the public API objects are not needed, they are really confusing for less experienced programmers and they are also a problem for PHP3 users (yes, a lot of PHP developer can't or don't want to move to PHP 4). I need to spend some time with the Zend API to see if it's really worth it for my time to go about doing it, but yes, I am very much considering turning it into C. I doubt that it is worthy, not just because of the conversion risks but also the maintenance costs. Instead, if you would like to join and contribute of Metabase, look here for this poll and tell how would you like to participate. http://www.egroups.co.uk/surveys/metabase-dev?id=392814 Metabase is available for free and over 4.000 unique PHP users downloaded it from here: http://phpclasses.UpperDesign.com/browse.html/package/20 There are several ready to use components based on Metabase like this for browsing query results: http://phpclasses.UpperDesign.com/browse.html/package/130 or even full application frameworks like Binary Cloud: http://www.binarycloud.com/ Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development 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 Development 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-DEV] database abstraction layers [from: MySQLfeature/bug]
Hello Sean, On 04-Feb-01 16:09:21, you wrote: This is something that PHP has always lacked. Its also something that I have always found to be the most attractive about application servers like Allaire's Cold Fusion (http://www.allaire.com/). The ability to totally abstract database access makes it much easier on the developer and transparent to the end-user. Metabase assures this for you. Metabase goes further, not only it assures portability of the application acceses to the databases, but is also to install database schema from a database independent schema definition format base in XML. This means that only need to tell which tables, fields, indexes and sequences in a simple XML file and Metabase manager installs it for you in any of the supported databases seeminglessly. The cool part is that if you want to change your database schema (and often you do), you just need to change the schema definition file and Metabase manager will update your schema without disturbing any data added to the database since the database was first installed or was updated for the last time. PEAR is fine for most people (myself included) but from an efficiency standpoint, this would be much better handled from the PHP API level, and not from the PHP language level. Metabase API is made of simple functions (not objects that you have to create). Doing what Metabase already does with built-in functions would not buy you much that would be worthy. Manuel Lemos Hello Mark, On 31-Jan-01 16:33:56, you wrote: I have been crafting my own database abstraction layer, and in doing so create an array of the results of a query. Is this an db abstraction layer written in php (script), or written as a module for php (C)? I was thinking of writing an (open source) db-abstraction module (that uses existing db-modules, of course), which could then be used from php-script as well as from other modules that need db-functionality without committing to a specific database. Or, does such a module exist already and should I concentrate on using and/or co-developing that one? I'd be open to turning it into C, as all my layer is really doing at its core is to do every single bit of error checking and API utilization for all the different DB drivers present on the system. Before trying to re-invent the wheel, maybe you would like to take a look at Metabase. It is not yet written in C, but nothing stops it from being converted. Unlike others it assures inter-database application portability. What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly see the point of using objects to do the work that a general function would do just as well and without any need to instantiate it. Objects are important to interface with different database drivers using the same API, but yes for the public API objects are not needed, they are really confusing for less experienced programmers and they are also a problem for PHP3 users (yes, a lot of PHP developer can't or don't want to move to PHP 4). I need to spend some time with the Zend API to see if it's really worth it for my time to go about doing it, but yes, I am very much considering turning it into C. I doubt that it is worthy, not just because of the conversion risks but also the maintenance costs. Instead, if you would like to join and contribute of Metabase, look here for this poll and tell how would you like to participate. http://www.egroups.co.uk/surveys/metabase-dev?id=392814 Metabase is available for free and over 4.000 unique PHP users downloaded it from here: http://phpclasses.UpperDesign.com/browse.html/package/20 There are several ready to use components based on Metabase like this for browsing query results: http://phpclasses.UpperDesign.com/browse.html/package/130 or even full application frameworks like Binary Cloud: http://www.binarycloud.com/ Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development 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 Development 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] Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?[EMAIL PROTECTED] -- E-mail: [EMAIL PROTECTED] URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp -- -- PHP Development Mailing List http://www.php.net/ To unsubscribe, e-mail: [EMAIL PROTECTED] For
Re: [PHP-DEV] database abstraction layers [from: MySQLfeature/bug]
I have been crafting my own database abstraction layer, and in doing so create an array of the results of a query. Is this an db abstraction layer written in php (script), or written as a module for php (C)? I was thinking of writing an (open source) db-abstraction module (that uses existing db-modules, of course), which could then be used from php-script as well as from other modules that need db-functionality without committing to a specific database. Or, does such a module exist already and should I concentrate on using and/or co-developing that one? Thanks, Marc. I'd be open to turning it into C, as all my layer is really doing at its core is to do every single bit of error checking and API utilization for all the different DB drivers present on the system. What I've seen of PHPLIB and PEAR's DB function don't interest me. I hardly see the point of using objects to do the work that a general function would do just as well and without any need to instantiate it. I need to spend some time with the Zend API to see if it's really worth it for my time to go about doing it, but yes, I am very much considering turning it into C. I've really been hoping that someone was going to take an intermediately complex Zend extension and put together a how-to that would help beginners and advanced programmers alike. I think there is a real need for someone or a group of programmers to get together and write a step-by-step theory/implementation "cookbook" for the sake of the community. Should I reach that point, I'd be happy to do it, but I tend to believe that the community could do it faster and better than I could right now, and that if if such a document were made publicly available, the community could build more and better core tools faster. My 2 cents...:) -- Per the initial question I posted, can there at least by made available a newer option for mysql_fetch_array() such as MYSQL_ALL, which would then give you null and non-null associative names? Mark J. Hershenson [EMAIL PROTECTED] http://www.green-ant.com/ -- PHP Development 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]
