Re: OCI8 extension

Thies C. Arntzen writes:

On Wed, Aug 07, 2002 at 03:55:00AM +0900, Maxim Maletsky wrote:

Guys, I was wondering about the progress on OCI8 extension. It seems like the last commits were made over 3 month ago. At my work we are extensively using Oracle (a government project) and I've been going on and on with workarounds without seeing much new updates to the module. Also, now Oracle 8 is already becoming an old thing. I guess time came fully supporting Oracle 9. In my own opinion, this must be scaring lots of (large) projects using PHP.

    we do fully support oracle9, the api for o9 is the same as
    for o8. o9 just added new things which are not available
    thru php as of now -

IMHO, these new things could be added without any enourmous efforts. I studied a bit oci.h/oci8.h and I saw the pattern. I think lots of functions are ok, however many need to be supporting newer datatypes (as you also mentioned) for Oracle 9. One other thing Oracle 9.2 is going to support is XMLTYPE, that can be an idea of implementing with PHP. Would be very cool with this XML fever of nowadays.

What are the plans of maintainers for the near future? Can I be contributing to the development with my good will, Oracle experience and little C skills? :)

    there are a few things i'd like to do in the oci-extension -
    but very limited time. contributions are always welcome, what
    do you have in
    mind?

I will continue... One FONDAMENTAL thing for PHP/Oracle extension is to support as much Oracle datatypes as possible. I could not yet figure out why only strings and integeres are supported when binding the valiables. In our project, 70% of Oracle interface is PLSQL. This is because the project is quite big and the database is anourmous (It is the national territory database for the Italian Government). The choice was to create stored procedures and interface only those from PHP, so behind the scenes, DBA guys can keep the database design independent from client application. But, the biggest problems that we had calling st-procs was impossibility of rietriving directly RECORD types. It wasn't possible to send a cursor result to PHP and instead we were passing its reference to then do another OCIExecute. It was a pretty big headache and recsource consumptions. We also need to create personalized libraries and do lots of specifications within the code while binding variables. And, Thies, all that required direct modifications within Oracle area... with such DB as Oracle this is not nice to need to changes in. I think lots of DBs that interfacing to client written in different programming languages cannot choose PHP for this very reason. To add, it was harder using boolean types. We resorted to 1/0. And, bools are often used in DB designs. Oh well, I am sure you know all those things better than I do. So, that is what I would like to work on. Another thing I was wondering is the naming used for the extension and function names. 1. How come OCI module is named OCI8 (specifically)? I think this makes it hard for many to believe that it can fully be compatible with upcoming releases of Oracle. Lots of businesses count a lot on application life-times and, seeing '8' (or so would be with '9') makes management feel that they might not be able to upgrade their expensive Oracle licences till PHP comes up with some newer number on the extension name. Which, in our case means changing the whole extension and, I really don't think we would be doing that too often. I personaly would see Oracle extension better with one only generic name like OCI, ora, oracle or whatever but not version-labeled. 2. Functions are called OCI .* I do well know what it refers to, but wouldn't it more standard for PHP to use similar naming as mySQL, pgSQL, MSSQL extensions ect? OCI make it a bit confusing, I always heard from my co-workers. These are the thing on my mind. And, I am very keen on adding a better Oracle support for PHP. Regards, Maxim Maletky maxim@php.net