On Tue, Oct 15, 2002 at 05:41:59PM +0200, [EMAIL PROTECTED] wrote:
>
> 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.
cool. how do you want to do this? php only has support for
strings and numbers. so we would have to add PHP resources
for all the other types.
>
> 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.
haven't really read the oracle-docs on that one. could you
give me a doc-link for this?
>
> 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.
yep, agreed. even though i don't use it myself i think it
would be great if we could support them. have you had a look
at the collections stuff in oci8.c?
>
> 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.
the functions are all called oci_*(). the name of the
extension is not really visible (unless you "configure" php).
i don't see this as an issue at all,, but -sure- we could
rename the extension.
>
> 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.
see #4.
>
> 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
that one should be easy to fix - looking at it right now.
>
> 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 :)
you have karma now.
re,
tc
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
