RE: [PHP] DB stuff

Hello Andrew, On 13-Nov-00 18:48:26, you wrote: >> Dennis explicitly asked for database abstraction packages that provide >> server independence. ODBC does not provide that because you often need to >> know how to handle with the underlying DBMS in your application to handle >> things that are specific. >> >> Think for instance about date fields. ODBC does not guarantee that >> selected date values will always be returned in the same date format. You >> have to sort that out in your application. >ODBC actually does guarantee that date values will be returned in the same >format. >As long as you use proper escape syntax, ODBC will take that and translate >any needed changes against the back end. >e.g. Select * from Table where Date = {d '2000-11-17'} will determine what >order. Does this work with all ODBC drivers? >Also, specific database settings can be passed on server setup; a programmer >can certainly tweak an environment variable from dd-mm-yy to yy-mm-dd if it >is essential, without changing the app at all. That's what Metabase drivers do if and when necessary. The programmer that uses Metabase does not have to worry with that and so he can develop portable applications without worries. >> >3. a DB abstraction class or layer such as Metabase, PEAR, etc/ >> - database >> >abstraction, and therefore easier database app building, but the >> paradigm is >> >to hide logic in functions. You aren't always sure what you are >> getting and >> >since it's not standards based you are limited to using it in individual >> >circumstances - and why not roll your own database classes if >> you are going >> >to do some real programming anyways? >> >> This is an heavily biased statement towards ODBC. We know your company >> sell ODBC drivers and it is expected that you would favour a ODBC >> solution. >Absolutely, I am quite heavily biased towards ODBC - to the idea of ODBC >though, not just my company's implementation of it. >PHP is a language that exceptionally facilitates dynamic webpages creation, >yet still allows granular control over the content of those pages. I don't >think that Metabase and ODBC necessarily conflict either, in fact I think >that ODBC is a great complementary piece here - the issue I have is that >Metabase, or any application framework, can eliminate the need for a PHP >developer to learn to handle much of the structuring of dynamic websites, >and replace it with a need for the programmer to learn a specific framework. The point is that Metabase is a framework that lets non-database expert developers (99% of the Web developers) write applications that can work with different database API and so they can switch database backend server without having to rewrite his application or learn a new database API. The truth is that most Web developers never heard of database programming before they started developing for the Web. Choosing the database that is better for each one is often dramatic. Developers often don't have the knowlegde to determine which criteria is important to make the the choice. A database API like Metabase takes from the developer the burden of making the wrong choice because later they can change without hassle. >I have nothing but respect for your skills and accomplishments Manual, and I >think you perform great services to the web development community, but if >everyone using PHP adopted Metabase and things like it, then wouldn't >something be lost? Isn't this how bloat creeps into software languages? I >don't want PHP to turn into something like Java or even Powerbuilder, where >there is a widget for everything, whose code does 3 things you want it to >and 27 things you may not use, and the best people using it are the one's >whose personal viewpoints mesh best with the idiosyncrasies of the tools. That's your personal point of view. If you go to Metabase page in the PHP Classes site, you can see that over 3,200 developers (unique users) downloaded Metabase. There are real needs for database independent API for PHP. For these people, portability and consistency is more important than dealing with each database API directly. Another great point of using Metabase as database API standard is related with a bunch of components that I am about to release for doing things that you need every day in your applications like displaying and editing data synchronized with the Web forms including database based field validation and so on. If you don't have a consistent API that assures portability like Metabase does, you can hardly make any reuse of these components when you try to use them with different databases. >I am looking quite forward to PEAR, as well, but I hope it becomes something >like DBD:DBI, though not a framework on top of PHP that hides granular It's not true that Metabase hides granular control. >control. I believe that abstraction layers need to address impedance >mismatch, and go no further, to allow complete abstraction from the back >end, without restricting the options of developers. To this end work still >needs to be done on things like cursor handling, statement preparation with >bound parameters, etc. Metabase does that since a long time before it was publically released. >> I can't speak for Pear, but if you look well over Metabase you >> can see that >> it comes with a driver compliance test script that is used to >> assure that its >> API works exactly the same regardless of the underlying DBMS you can work >> with. >Isn't this what ODBC does?? The API, if followed, provides this assurance. >PHP has much of this implemented already. The point if that you were claiming that you would not be sure what you get from packages like Metabase. >> For instance, I can't tell whether the underlying database supports >> sequences. Another thing, although I can figure if the underlying DBMS >> supports auto-increment fields, I can't figure how to retrieve the last >> value that was inserted in auto-incremented column after I execute an >> INSERT statement. The ability to access to sequences or auto-incremented >> fields is vital for Web applications because they need to handle >> consistently concurrent accesses. >Absolutely, but I would argue these things should be integral to a >web-optimized language (via PEAR, perhaps?) and not something that should >sit in any way 'above' the language. It's certainly a level above ODBC. I don't see the point of making database abstraction API integral part of PHP. When you want to add new drivers of fix the existing ones you need to ask people to upgrade their PHP version which they often refuse to do even if they can. >> It's funny that you mention users are limited to use Metabase/Pear in >> limited circumstances because they are not standards based. The truth is >> that ODBC got somehow stuck in the time before the Web became a viable >> platform for database applications. >Untrue. The perception that ODBC is an old or slow standard exists because >there are old and slow implementation of it. I am not talking about the drivers, but about the capabilities of ODBC API. >> For instance, when you display query results in Web pages you may not be >> able to display the whole result set in a single page. What you >> usually do >> is to display a subset of the result rows in different pages. This is an >> every day need of Web database application developers. >Yes, it's called cursors. PHP's limited cursor support is not a failing of >ODBC, but a limit of the language. I would love to see it addressed as much >as you, but I differ in at what level it should be implemented. It's a different thing from what I am talking. AFAIK, cursors do not avoid database full scans on the server side which is a thing that brings down many servers when applications are not ready for big audience. Metabase select row range limiting is specified before executing a query. Cursors are used after the query is executed. The difference is that if you can specify the range of selected rows that you want to retrieve information, the server can act in a more optimized way and stop the query search sooner. In MySQL and others it uses the LIMIT clause or similar. In others that don't support that, the selected row range limiting is emulated. In some cases cursors are used. >> Since HTTP server access is stateless, you can't keep the same server >> connection between requests to serve pages to the same user. MySQL which >> is a modern database shaped to the Web database programming needs has the >> LIMIT keyword that is used to tell the server to only return a given range >> of rows. Other DBMS may have or not have the similar things. >Limit is a bit of a workaround though - again, databases should support >robust cursor models. LIMIT is perfect for the Web applications. People only want to show a range of selected rows per page. A lot of people hate other databases (say Oracle - only with DBMS_SQL package) than MySQL because they don't have the LIMIT clause support. >> What good does it do to ODBC being based on a standard if this standard is >> not adapted to the needs of Web programming developers? Not much IMHO. >> >> While we are at it, if you are really concerned in making ODBC a better >> option for PHP programmers, you may work on it's API to let developers >> be able to figure if a given result value is NULL or not, because >> currently >> it is not possible to distinguish if a text result value is NULL >> or is just >> an empty string. Another thing is not being able to figure if the >> underlying DBMS supports transactions. These limitation are in >> PHP ODBC API, >> not in ODBC API itself. >ah, as I reach the end it seems we are in many ways on the same page here - >but please don't slam ODBC in favor of workarounds, just because you have >built them. I agree that workarounds are necessary, considering the state >of some of these things (null fields, sequences, cursors) but standards do >exist that can be implemented to close the last gaps. Actually, there is no workaround for NULL field problem in Metabase. Several other PHP database API, like Mini-SQL and Informix. Funnier is Oracle that handles empty strings as NULL when inserting them in text table fields. Anyway, my greatest problem with ODBC is that it you can't abstract as much as I need for making database independent Metabase driver without prior knowledge of the underlying database. The solution for this is sub-class the ODBC driver to implement the functions that depend a lot on the underlying database capabilities that you can't figure from the ODBC driver query functions. I plan to develop some database specific ODCB drivers for Metabase, but I'm not sure when I will do it. So, I am always open to contributions. According to this poll, 20% of Metabase users want to use the ODBC driver. http://www.egroups.com/surveys/metabase-dev?id=263873 If you or anybody else is interested to develop any driver subclasses for Metabase ODBC driver, feel free to contact me and I will integrate your work. If you are so commited to promote the use of ODBC among the PHP community, I think this can be a great opportunity. Regards, Manuel Lemos Web Programming Components using PHP Classes. Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org -- E-mail: mlemos@acm.org URL: http://www.mlemos.e-na.net/ PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp --