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=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 > -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
