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
[EMAIL PROTECTED] [thanks to Ask Bjoern Hansen].  Send email to
[EMAIL PROTECTED] for info about how to subscribe etc.
Archives at http:[EMAIL PROTECTED]/ 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.

Reply via email to