dbi_bunce_at_work_on_oracle_oci_interface

This is part of The Pile, a partial archive of some open source mailing lists and newsgroups.



To: dbi-announce@perl.org, oracle-oci@perl.org
From: Tim Bunce <Tim.Bunce@ig.co.uk>
Subject: New Oracle::OCI module - pre-announcement
Date: Thu, 15 Feb 2001 01:43:14 +0000

This is a pre-announcement for Oracle masochists and/or people
who know what Oracle OCI can do and what to get at it from Perl.

To give you a flavor of what you're in for, here's a DBI connect:

  use DBI;
  DBI->connect("dbi:Oracle:", "scott", "tiger");

Here's the Oracle::OCI version of (essentially) the same:

  OCIInitialize(OCI_OBJECT, 0, 0, 0, 0);
  my $envhp = new_ptr('OCIEnvPtr');
  OCIEnvInit($envhp, OCI_DEFAULT, 0, $a=0);
  OCIHandleAlloc($$envhp, my $errhp=0, OCI_HTYPE_ERROR, 0, $a=0);
  $errhp = new_ptr('OCIErrorPtr', $errhp);
  OCIHandleAlloc($$envhp, my $svrhp=0, OCI_HTYPE_SERVER, 0, $a=0);
  $svrhp = new_ptr('OCIServerPtr', $svrhp);
  OCIHandleAlloc($$envhp, my $svchp=0, OCI_HTYPE_SVCCTX, 0, $a=0);
  $svchp = new_ptr('OCISvcCtxPtr', $svchp);
  OCIServerAttach($svrhp, $errhp, 0, $sb4_0, OCI_DEFAULT);
  OCIAttrSet($$svchp, OCI_HTYPE_SVCCTX, $$svrhp, $ub4_0, OCI_ATTR_SERVER, $errhp);
  OCIHandleAlloc($$envhp, my $authp=0, OCI_HTYPE_SESSION, 0, $a=0);
  $authp = new_ptr('OCISessionPtr', $authp);
  OCIAttrSet($$authp, OCI_HTYPE_SESSION, dvoid_p_str("scott"), OCI_ATTR_USERNAME, $errhp);
  OCIAttrSet($$authp, OCI_HTYPE_SESSION, dvoid_p_str("tiger"), OCI_ATTR_PASSWORD, $errhp);
  OCISessionBegin($svchp, $errhp, $authp, OCI_CRED_RDBMS, OCI_DEFAULT);
  OCIAttrSet($$svchp, OCI_HTYPE_SVCCTX, $$authp, 0, OCI_ATTR_SESSION, $errhp);

[It's all rather rough at the edges, but that's because I've only just
hacked it into working shape about a hour ago :-]

Why bother? Well, in practice, you wouldn't have to do all that.
I'll be extending DBD::Oracle to make the underlying OCI handles within
the DBI handles available. That way you can let the DBI and DBD::Oracle
modules do what they're best at and then use Oracle::OCI to do the extras.

What extras? Well, the Oracle 8 OCI defines hundreds of functions
that include things like Object Relational stuff, full LOB handling,
Failover, Direct Path loading, Advanced Queuing, Publish Subscribe,
Notification Callbacks, Transaction management (having multiple
processes participate in a single transaction) etc etc.

Basically the idea is that Oracle::OCI will provide access to the
*entire* Oracle OCI API.  That's everything described here:

http://technet.oracle.com/docs/products/oracle8i/doc_library/817_doc/appdev.817/a76975/toc.htm

(username/password required but free to get and worth it for Oracle users.)
 
I'll remind folk again that the Oracle::OCI module will not be for the
faint hearted. It's a very thin layer over raw OCI calls.  It'll also
come with almost no documentation because the Oracle OCI manual will
_be_ the documentation for the Oracle::OCI module.

If you think you might be interested in accessing the (vast) power of
the OCI interface from Perl then I advise you to start learning OCI now.

I hope and expect some people will start developing other modules
layered on top of Oracle::OCI to provide simpler access to specific
areas of it's functionality (like direct path loading, VARARRAY, named
data types, schema metadata, failover, queuing, object-relational,
object-caching, object-navigation, session/server/transaction context
management etc etc etc).

As it's not directly DBI related I won't use the dbi mailing lists for
it except where relevant. A new list has been setup at
oracle-oci@perl.org [thanks to Ask Bjoern Hansen].  Send email to
oracle-oci-help@perl.org for info about how to subscribe etc.
Archives at http://archive.develooper.com/oracle-oci@perl.org/ will
appear soon.

Tim.

p.s. No, this doesn't mean I'll be neglecting DBD::Oracle. Far from it,
I expect DBD::Oracle to grow faster leveraging the power of Oracle::OCI.

===


the rest of The Pile (a partial mailing list archive)

doom@kzsu.stanford.edu