I'm sure glad this in the headlines again ;-) As Thies knows, I already proposed another important change, which is supporting multiple character sets. This is very important on shared web platforms, and I have experienced the trouble that arises from the way the oci ext treats the session environment (-> as a global one). Oracle 9i offers some functions which help out from this dilemma, and I have changed the existing oci ext to support them. The most important change (from a user's viewpoint) is that OCILogon has an optional forth parameter, the character set, so an connection looks like this:
OCILogon($user,$pass,$tnsname,"WE8ISO8859P1"); Ok, I know this isn't ideal, since OCILogon already has an optional parameter, but maybe people can set $tnsname to false if they want to use the default one (ORACLE_SID) and use a specific character set? Anyway, my code works, and is already being used in a relativly big production environment. >From a developers viewpoint what I mainly did was follow Thies' proposal and put the >environment struct in the session struct, and use the global env only for init work. >Then I decode the character set parameter (if it is omitted, the NLS_LANG setting or >Oracle default will be used) and use it in open_session. Voila, Oracle takes care of >the rest. Works better than I thought :-). The only thing I need to do now is to add a compile-time decision on whether Ora9i libraries are found or not, and then to make this functionality available depending on the version. If anyone's interested I can send a patch.. As for the proposed name changes, IMHO it doesn't make that much of a sense, 1. since existing apps would have to be rewritten, and 2. there is absolutely zero effectiveness in merging the ora_ and OCI extensions, which differ greatly, into one. I think that would result in a mess or a big rewrite.. Thx, Cu Abdul "Sebastian Nohn" <[EMAIL PROTECTED]> writes: >> 5. Functions are called OCI .* I do well know what it refers to, but >> this is only because I learned the original oci.h API. Wouldn't itbe 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. >> Besides, this can also be a great input for newer Oracle's updates. > > This is mainly because there are Oracle-funktions and OCI-functions (there > is a difference), and i like the OCI-thing very much, it's much easier and > faster to type than oracle ;) Well, yes, OCI* functions look pretty geek, indeed, they are very similar (if not identic, in some its parts) to the actual OCI API. But, this naming convention is way not optimal, is limited functionality-wise and, last but not least, it is far not PHP's standard naming convention for the database extensions. In fact, if you'll look into PHP standards specifications (look in CVS: http://cvs.php.net/co.php/php4/CODING_STANDARDS?login=2&r=1.23) you are encoraged using a certain style for calling your functions, especially those of databases since these mostly do the same things. What I meant was, while to access a mySQL database you use mysql_connect(), for PostgreSQL pg_connect() and for Sybase sybase_connect() question stays: why function to connect to Oracle be called OCILogon()? Wouldn't it be better called oracle_connect()? that is how som other programming languages call it. It is not an exaggeration to say that, some programmers are actually making their own functions named this very way so they can easier interact with the Oracle database using their mySQL's (or whatever) habbits because OCI gets them confused. I kind of followed this question within the PHP-Oracle developers I met. For now, we have ora_* and OCI* functions. These are, as long as I understand, used for Oracle v6.* and Oracle v8 (the last one is also 90% compatible with v9). Yet, this shouldn't mean that there is no need for a standarized set of functions like oracle_* with mapped/intuitive functionalities like most of the DBs PHP that supports AND as compatible between Oracle versions as possible. Only this way, one could firmly admit that PHP fully supports Oracle database. Those are my ideas for the Oracle extension. At this point, some new questions arised in my head: 1. Is ora_* extension (ext/oracle) still maintained and ported compatibility-wise to the versions Oracle newer v6 or, for these are OCI8 extensions? If so, then this should mean that ora_* functions are limited to version 6 only, if not deprecated at all. Am I correct, or missed the point? If I guessed, then what was the need for OCI8 extyension at all? Why ora_* could not be continued? I still haven't found it out. 2. What costs merging the two extensions (ora_* and OCI8) in one (oracle_* ?) that fully supports both 6*, 8* and 9* versions of Oracle and remains the only one to be used (as well as maintained, debugged) in the feature? 3. Still, related to question 2: Wouldn't it be safe enough, if not rather strategically clever to introuduce the oracle_* new functions as a new unified extension for Oracle in all its versions within PHP 5? Considering, that we are still at the planning stage of its development release? Hope to see someone to anser, commenting my thoughts on this. I am very much willing contributing to the PHP's Oracle support development. Maxim Maletsky [EMAIL PROTECTED] [EMAIL PROTECTED] schrieb am 15.10.02 17:32:17: > Thanks, Andi. > > yeah, I will wait for Thies to reply to me. We have sort of a started > this discussion with him before, so hopefully he will join into this one. > > My main concerns about OCI8 are the followings ones. Some of them are > related to the opverall idea of PHP-DB usage, some to the actual > performance and some to the missing functionalities. Some, might be > bogus or hardly accomplisheble. Here's what I think: > > 1. Datatype support. Right now, OCI8 only supports string and integer > datatypes binded via PLSQL. It would be great being able to use all the > remaining ones like booleans and dates, the other, incompatible onces > might need to be translated into PHP's way so they can be used within > PHP. Main problem of this is that, tipically, DBAs would grant the > access via PLSQL (stored procedures) to a various number of clients, > applications and langueages. Since, PHP does not funny support PLSQL, > interfacing Oracle via PHP not having to change stored procedures is > very limited. > > 2. XMLTYPE. This is new since Oracle 9.2. Will all the XML fever of > today, wouldn't it be possible to add some extra compatibility for it to > stipulate Oracle users using PHP? Always if this is dopable and logical. > > 3. Record type from Stored Procedures. (similar to #1) This is a VERY > BIG limitation. It is, probably, the 50% of the reason why PHP is not > used much with Oracle. Most programming languages can retrieve RECORD > type from stored procs. and use it as arrays of data (like plain SQL > records return). PHP fails on it, it only allows you to return the > cursor, and for that you need to modify (descresing so performance) the > stored procedures directly. At my work, (Italian Government) a datadase > had over 500 stored procedures used via other programming languages. To > migrate onto PHP, these all had to be changed and the backwards > compatibility to the previous programming language was completely lost. > It's a big issue. > > 4. OCI8 module naming conventions. 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. > This could also help us keeping the OCI8 intact while adding newer > changes. > > 5. Functions are called OCI .* I do well know what it refers to, but > this is only because I learned the original oci.h API. Wouldn't itbe 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. > Besides, this can also be a great input for newer Oracle's updates. > > Here's one of the sample bugs that can be occuring while continuing the > current OCI8 extension with Oracle 9 and so on... > > http://bugs.php.net/bug.php?id=18758 > > Hope, Thies and the rest of Dev Group can comment on my thought, and try > to think of a way improving PHP's Oracle support so we can start working > on it. Btw, I do not have a karma for php4, so keep that in mind :) > > -- > Maxim Maletsky > [EMAIL PROTECTED] > > www.PHPBeginner.com // where PHP Begins > > > > Andi Gutmans <[EMAIL PROTECTED]> wrote... : > > > Hey, > > > > I'm sure that if there's work to be done people using Oracle will > > appreciate your contribution. > > Personally, I don't use Oracle so I suggest you talk to Thies who's the > > maintainer of the extension about the things you feel are missing. (It can > > also be public here on php-dev if you need feedback from other users). > > > > Andi > > > > At 01:51 PM 10/15/2002 +0200, Maxim Maletsky wrote: > > > > >Guys, a few month ago, I have been trying to offer some of my help for > > >developing Oracle 9i extension, or in anyway, to improve the existing > > >PHP/Oracle functionality. > > > > > >original posts are here: > > >>http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=aiquvp%2412e7%241%40FreeBSD.csie.NCTU.edu.tw&rnum=120&prev=/groups%3Fq%3DOCI8%2Bgroup:mailing.www.php-dev%26hl%3Den%26lr%3D%26ie%3DUTF-8%26scoring%3Dd%26start%3D110%26sa%3DN) > > > > > > > > >Having put onto the real-life test OCI8 extensions for the Italian > > >Government framework, I noticed many serious imperfections with the > > >current OCI8 extension. > > > > > >I personally think that Oracle is very important for PHP's future, and > > >that current extension is not very perfect and up to date. > > > > > >Please let me know if you are interested in my contributions regarding > > >it. > > > > > >-- > > >Maxim Maletsky > > >[EMAIL PROTECTED] > > > > > > > > >-- > > >PHP Development Mailing List <http://www.php.net/> > > >To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > -- > > PHP Development Mailing List <http://www.php.net/> > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > -- > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
