<[EMAIL PROTECTED]> wrote... :
> Hm, quite a few issues... Here are my thoughts regarding one of them.
>
> > > 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.
> >
> > Well, ideally, there would be a function for charset to be called before
> > any OCIParse and set the charset. This would be:
> >
> > 1. more flexible
> > 2. would exclude non-authentication functionality with OCILogon
> > 3. easier to find for a user
> >
>
> Well basically, yes, I would prefer that solution, too. But: OCILogon not only
>connects to the database, it also opens the session, which is quite correct since a
>connection without a session isn't very useful. So either we make OCILogon *just*
>connect to the db and have a useless connection lying around until someone
>initializes the session (-> quite a bit to change + programming logic in php scripts
>broken, they would have to do two initialization steps), OR we initialize the session
>together with the connection (as is now) but have to provide the parameter at init
>time.
>
> Wait, there is another possibility: perhaps we can have OCILogon use the global
>environment OCI(pEnv) to init the session (meaning that it uses the NLS_LANG
>settings), and then one can (not must) change the environment and from that moment on
>the new environment is used for the session. But this means we have to have a
>reliable switching mechanism between global and session-private environments,
>something I believe to be very tiresome...
I would think of using the _ENV variable on logon, so you can set it
right before doing OCILogon. Well, one of the other methods I can
picture:
1. change in INI ini_set();
2. Setting Local enviroment by using setlocale().
The last one looks quite elegant to me, but is only available for
language charset, ENV alteraction could also help changing other data
later on. What are the other DB extension's work arounds about similar
things?
> Besides, we would then have a PHP function that can only be used with oracle 9i,
>whereas I would prefer to have a parameter that is only supported on such systems.
>Maybe just a matter of preference, but I feel that a function that is only available
>in certain compile situations isn't very elegant...?
Better non version-depend for compiling.
> BTW, currently the environment is init'd in php_oci_init_globals using the OCI
>function OCIEnvInit, which is deprecated. We should try to switch this to the more
>flexible (and supported) OCIEnvCreate - just as a small note ;-)
>
> I included the patches (oci8.c and the corresponding .h) but please remember that
>currently you will need an Oracle 9i client to compile them (I still need to put some
>switches and fallback behaviours in there).
I think, at this point, it is up to Thies to review the patch.
--
Maxim Maletsky
[EMAIL PROTECTED]
www.PHPBeginner.com // where PHP Begins
>
>
> >
> > > 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..
> >
> > Well, let's ask Thies if he wants the patch, as I have no karma to php4 anyway :)
> >
> > > 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
> >
> > No way,I meant to drop the existing compatibility :).
> >
> > I'd keep the existing OCI8 extension, as well as I would keep ora_*
> > functions. I would simply add the earlier suggested oracle_* functions
> > to be something understood as a default Oracle extension similar to the
> > way other DBs work. That's my idea. the -1's are that someone can get
> > confused. But, nothing is free, I think a bit of confusion is the
> > minimal expense for such functionality. it's already confusing anyway.
> >
> > > 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..
> >
> > Wouldn't it be better, though? Yes, perhaps it would be a big rewrite,
> > but it would definitely create an actual Oracle extension, not
> > two version-specific ones. Really, it is confusing.
> >
> > Try imagine a similar situation:
> >
> > Whoever pays Oracle license is planning something big and costly. A such
> > "user" would have no much trouble paying also for Java or ASP, that
> > support Oracle pretty well, but, should the corp. prefer PHP, they'd
> > consider this more than once.
> >
> > This is because they would be soon confused about how things are working
> > between PHP and Oracle, what Oracle versions are supported and for how
> > long... Then, automatically (in some heads) answer arises: "Yeah, PHP
> > is Open Source, it won't support well commercial third parties...".
> >
> > That is why I think that unifying Oracle into something that looks and
> > works just as other Open Source DBs can help PHP (5?) gain better trust
> > and confidence from middle-large projects worldwide.
> >
> > I have this theory not from air, but from my experience as a consultant trying
> > propose PHP for Oracle Dbs :)
> >
> > Maxim Maletsky
> > [EMAIL PROTECTED]
> >
> >
> > > 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
