Re: Architecture was: Re: Q: eXt. Procs. - callbacks

A copy of this was sent to "huh" <huhhy_at_rocketfdasfdsafdmail.com> (if that email address didn't require changing) On Fri, 6 Aug 1999 10:16:00 +0200, you wrote:

>> OCI is the Oracle Call Interface, this is the lowest level interface you
>as a
>> programmer can code to directly. It is layered on top of Oracle's
>internal API
>> called UPI/OPI. If you want to code natively in C with no pre-processor,
>this
>> is what you would use.
>>
>
>I looked at Oracle Net8 Administrator's Guide,
>figure 2-6 Typical Communications Stack in an Oracle environment.
>
>Could you tell us which layer provides UPI/OPI APIs?
>

upi would be right below oci on the client side. opi is in the diagram already on the server side.

>>
>> The precompiler folks have their own (undocumented) API called SQLLIB.
>You
>> cannot code to SQLLIB yourself. SQLLIB is a layer on top of UPI/OPI. It
>is
>> what pro*c and the other precompilers "precompile" into. You cannot code
>(nor
>> would there be any good reason to) directly to SQLLIB. If you want to
>code
>> directly to an API, you would use the documented and supported OCI layer.
>>
>
>So SQLLIB would be at the same level as the OCI at figure 2-6, wouldn't it?
>

yes.

>>
>> It is fairly portable C code.
>>
>
>Portability is ensured by preprocessor. However development tends to C++.
>What about the C++ support? Class libraries...?
>

you were talking about us having to port 2 api's -- sqllib and oci -- and what a bother that must be.

sqllib and oci are implemented in a very portable fashion by us. we can port them very easily.

you on the other hand, when you start using c++ and class libraries etc are limiting your portability. C++ isn't as portable as C yet (might never be) and the class libraries definitely are not as portable as the standard C api is yet. We don't code our database stuff in C++ tho.

>>
>> OCI is not a good candidate for Pro*C to
>> precompile into. The Pro developers have an API that is easy for a
>program to
>> generate calls to. OCI is written for the developer themself to generate
>calls
>> to.
>>
>
>Mhhhhhh. Could you give us an example where OCI doesn't suite well
>for preprocessor and how SQLLIB solves this?
>

different api's for different things. Pro*C likes to stuff bunches of globals at the top of your application. It fills in C structs with pointers to your information and then makes a single call to sqlcxt with this structure to do anything.

If you look at precompiled pro*c code. All statemtents you code that actually generate code (eg: an EXEC SQL BEGIN DECLARE SECTION does not generate code) all do this:

   fill in various elements in the sqlstm struct    call sqlctx()
   check error codes.

Every EXEC SQL statement = 1 function call with a structure telling it what to do. If we converted this into OCI on the other hand, we would have many many function calls to do this work. For example, if I execute a statment with bind variables -- in OCI i must parse, bind for each variable, and execute. In Pro*c we load up a structure with the statement, we set an array to point at each bind variable and we call sqlctx -- one function call (that ultimately gets translated into many UPI calls).

>>
>> ODBC is not a call level interface for Oracle that we maintain directly.
>ODBC
>> is an API that is layered on top of OCI by people.
>>
>
>IMO it depends how the driver was written.
>I don't have a crystal understanding of
>Client Side Communication Stack but it must be possible
>to write an ODBC driver which will reside at the same level
>as OCI and communicate with the same layer as OCI does (UPI/OPI).
>It is no problem for ORACLErs, however for independent ODBC driver
>vendors it depends on knowledge they can only get from ORACLErs
>
>BTW: Server side OPI interface. Can I find any documentation somewhere?

In general no. Its an internal api.

--
See http://govt.us.oracle.com/~tkyte/ for my columns 'Digging-in to Oracle8i'... Current article is "Part I of V, Autonomous Transactions" updated June 21'st  

Thomas Kyte                   tkyte_at_us.oracle.com
Oracle Service Industries     Reston, VA   USA

Opinions are mine and do not necessarily reflect those of Oracle Corporation Received on Fri Aug 06 1999 - 08:18:43 CDT