"Thies C. Arntzen" <[EMAIL PROTECTED]> wrote... :
> 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.
Boolean can be used, we can always determine that a boolean is being
binded against a boolean PLSQL value. So that is one. Then, for OUT or
IN/OUT you can return RECORD type converting it into an array, just like
the OCIFetchStatement does. These are my guesses.
>
> >
> > 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?
Sure, the link is below. Basically, to describe it in two words, XMLType
is somewhat like storing XML data in CLOB, the benefit of it is that you
can search, sort and retrieve by tag, and more. For instance you can say
"select the contents of this tag within this XML data" directly from a
query without having to retrieve and parse the whole XML code. Very
useful for many cases, and, I do not really see yet how well this could
be implemented right now, it is only Oracle 9.2 feature, but I thought
to consider it, seeing how much is going on with XML nowadays.
XMLType:
http://www.oracle.com/oramag/oracle/01-nov/index.html?o61xml.html
>
> >
> > 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?
Yeah, I looked at them. Still, didn't figure everything out completely,
but I saw the point. This is a MUST. I think RECORD type is the first
reason to discourage real usage of PHP with Oracle. Without it, many
projects simply do not use PHP for Oracle, they simply cannot start it.
That is why it is never seen in bugs or lists :) No one can use PHP if
needs it. Unless, you go for using cursors, but that requires you to do
several major changes to the stored procedures themselves, and is only
possible if the stored are used for only PHP, if these are shared with
more languages, such change is unthinkable. It's a must in other words.
> >
> > 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.
I agree on this one. Name of the extension does not really matter. It is
confusing though having two extensions for each version, but still
survivable.
>
> >
> > 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.
well, in this one I want to split the thread. OCI* functions is, in my
opinion, an incorrect way of DB usage for Oracle. It should be a
standard naming like oracle_num_rows() and so on. We do have ora_*, that
is good. But, I think to continue the development of Oracle support we
shouldn't split into ora_* and OCI, but rather have one of them only.
Probably ora_* or oracle_*.
> >
> > 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.
Good.
> >
> > 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.
Sweet! Thanks for that. I will start from learning more on the OCI8 ext
and fix some bugs. Probably will bug you a lot with questions :)
--
Maxim Maletsky
[EMAIL PROTECTED]
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
