On Thu, 2004-11-18 at 11:41 -0700, CHRISTOPHER.JONES@xxxxxxxxxx wrote: > During my presentation at the PHP Conference in Frankfurt I put > out a call for participation in creating a roadmap for Oracle > connectivity in PHP. > > When I get back to work (I'm on a short vacation in Europe with > intermittent email access) I'll be following up on this. While I'm > away, feel free to fill my inbox with suggestions and discussion > of your application architecture requirements. I've been recently looking into the OCI8 extension. Alas, with PHP5 and multithreaded web servers (Apache2 et.al.), the connection handling seems to be completly broken. Using PHP5 and the current oci8 module in an mt environment leads to sessions stacking up on a single server connection without getting closed nor reused. I didn't try the classic multi process environment, but I suspect the same broken behaviour to show up. So what you get right now is a non working session multiplexing (ala Oracle MTS) which surely is not what people want when the need "connection pooling". Another area where PHP Oracle support needs improvement is national charset support. Currently NCLOBs simply don't work. Additionaly, the LOB handling support is more complex (using implicit LOB descriptors) than it need to be, taking into consideration the LOB handling capabilities introduced with OCI 9.2. Using the new thread safe hash lists of PHP5, I've successfully implemented (let's say proof of concept quality ;-)) an extension based on the current OCI8 code that can use native OCI session pooling (instead of implementing own connection pooling code) and is able to handle national character data while mostly retaining backwards compatability - "normal" connects are still possible besides predefinded pools. So what to do? While I see great potential in PDO, having a common API as in JDBC or ODBC would be great, it seems there isn't much development going in that direction. Additionaly, every application would need a major rewrite to switch from the current oci8 extension to something different. So, building on the existing OCI8 extension and improving it in the afore mentioned areas seems to a pragmatic approach while retaining PHP API compatability for people already using Oracle with PHP. This would mean dropping support for client libraries before Oracle 9.2, making it possible to throw away much of the convoluted legacy stuff in the connection / LOB handling code. Remember, with OCI client 9.2, you can still connect to 8.1 databases. If there is still demand for connecting to pre 8.1 databases, people would have to stick with PHP4, which seems to me reasonable. Any comments are welcome to better support the greatest RDBMS with PHP ;-) -Andreas -- Andreas Karajannis mediaworx berlin AG Fon (030) 2 75 80 - 266 Fax (030) 2 75 80 - 200 -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
