Re: Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 10:22:04AM +0200, [EMAIL PROTECTED] wrote: 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.. i'd love to see that patch integrated! can you send it to me? re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: Re: [PHP-DEV] OCI extension help offer
On Wed, Oct 16, 2002 at 10:26:46AM +0200, [EMAIL PROTECTED] wrote: Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. hmm, sure - why not. we could start to brainstoorm about that and decide if we need to rewrite or just add to what's there. what are your plans, what features do you want to see? i have things like failover and connection pooling (for threaded servers) that i'd like to see in the future. re, tc -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] OCI extension help offer
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=2r=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
Re: Re: Re: [PHP-DEV] OCI extension help offer
Oh, and just to be clear about it: I am absolutely positive on a completely new (perhaps unified) extension for PHP 5, and would gladly participate. I Just don't think that changing anything in the current situation would be useful. Abdul [EMAIL PROTECTED] schrieb am 16.10.02 10:22:18: 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=2r=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
RE: Re: [PHP-DEV] OCI extension help offer
-Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Envoyé : mercredi 16 octobre 2002 10:22 À : [EMAIL PROTECTED] Objet : Re: Re: [PHP-DEV] OCI extension help offer I'm sure glad this in the headlines again ;-) +1 As Thies knows, I already proposed another important change, which is supporting multiple character sets. Do you know if/when your patch (or similar functionality) will be included in the oci extension ? 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.. It might be interesting to change only the extension name from oci8 to oci (which would be less confusing when working with 9i). Unless your code relies on extension names, it will still work. -1 for merging ora_ with oci_ extensions unless you can disable ora_* functions at compile time (I don't want my users to be able to call ora_*). Jean-François -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] OCI extension help offer
[EMAIL PROTECTED] schrieb am 16.10.02 14:27:35: I think, at this point, it is up to Thies to review the patch. I hope he's not too harsh on it ;-), since this code is certainly *not* ready for merging into the cvs tree. Meaning: it merges perfectly, but doesn't compile correctly on Oracle 8i systems, only on 9i - as I said, this is still on my TODO list. Abdul -- PHP Development Mailing List http://www.php.net/ To unsubscribe, visit: http://www.php.net/unsub.php
