Some questions about odpi about odpi

[cjbj]

@vrogier OCILIB is a great API - thanks for pinging.

To address a couple of questions, ODPI-C is a new API so supporting the 11.2 client is the way forward. It lets us work with the current technical features of 11.2, 12.1 and 12.2 clients, and lets us focus our development and testing efforts. Users can still connect back to 9i databases.

When we get the cx_Oracle driver updated to ODPI-C, you'll see the object support. @anthony-tuininga may have other comments.

@anthony-tuininga was doing a bit of UTF16 investigation during development. If you have testcases/bug numbers for the OCI UTF16 issues you mention, email me (see my profile). General ODPI-C testing is ongoing. The initial focus is on making sure the cx_Oracle and node-oracledb drivers are stable.

ODPI-C is an open project, so features can be added as priorities arise. I don't want to see the API creep too much from its focus on scripting drivers, and I don't want to see it replicate OCI. It should add value on top of OCI. Anthony is working on adding some 12.2 features at the moment, e.g. Sharded DB support. Yell out with your wish list.

Overall I suspect you will want to keep OCILB on OCI but it's definitely worthwhile doing a proper evaluation.

[anthony-tuininga]

@vrogier Chris already discussed the fact that 11g R2 clients are capable of connecting to 9i databases so the limitation to an 11g R2 or higher client shouldn't be too onerous. I certainly haven't experienced any issues with limiting support for the cx_Oracle driver to 11g R2 and higher!

I have tested with UTF-16. Using the new cx_Oracle driver based on ODPI-C I have been able to run the complete test suite perfectly using the UTF-16 encoding (and UTF-8 encoding). Some effort has been made to compensate for issues in OCI when managing UTF-16. I can look at the memory leak issue with OCIObjectSetAttr() and OCIObjectGetAttr() -- if you have an example that demonstrates the problem that would be helpful. And if there are other known issues, please let me know!

There is already support for all SQL and PL/SQL types and collections -- including varrays, nested tables, records and collections of records. There are no samples currently for these but, as Chris mentioned, the cx_Oracle driver based on ODPI-C does support it so you can look at those when it is released.

Regarding the other features (direct path and user callbacks) it would be useful to have examples that demonstrate their use so that we can evaluate whether or not such support should be added into ODPI-C. If you have other suggestions we'd love to hear them!

[vrogier]

@cjbj n @anthony-tuininga , Thanks for your replies!

About OCI version support, your position make sense regarding server side versions. My concern was more about the fact that sometimes, applications cannot deploy their required Oracle Client versions and must rely on existing deployed client installations. I still encountering people deploying applications using OCILIB in Oracle 8i/9i client environments! Even if they are out-dated legacy environment, is there any reasons (other than internal code complexity) for restricting older versions ? Maybe because odpi does not support runtime loading of OCI shared libraries ?

About UTF16 issues:

• leak in describing column name: oracle bug #9838993 (not resolved so far in 12cR1)
• OCIObjectSetAttr() crash: oracle bug #66885036 (still present in 11gR2, don't know about 12c)
• OCIDBStartup() failed in UTF16 mode (at least using 10gR2)

When odpi-c based cx_Oracle driver will be released ?
I will definitely have a look at it :)

User callbacks is a nice way to add tracing capabilities, providing testing capabilities and moreover the ability to connect to other db backend by providing OCI calls remplacement. I'm currently working on its usage in OCILIB (tracing and replacement).

OCILIB code base is now 10 years old, and although it brings to users a full-futured and easy API on top of OCI, making evolutions to it is not straightforward. It heavily relies internally on macros to minimize code base size, some design errors made years ago are a pain to maintain (for backward compatibility reasons).
Thus i'm currently thinking about planning a full rewrite for its next major version. First idea is a C++ implementation with a C binding on top (As I'm already aslso providing a C++ OCILIB API).
That's when i found ODPI and its interesting idea of mutualized driver code base that I cannot ignore.
Thus i'm really interested in it and will try to analyze the gap in current odpi scope and OCILIB OCI coverage. If he gap is not too big and addressable, I might try to make a PoC based on ODPI.

Best regards,

Vincent

[cjbj]

@vrogier If you want to email us (see my profile), we can set up a call - this would be higher bandwidth than GitHub issue updates! There's a lot we could discuss on both sides.

Re UTF16

• 9838993 was determined to be an application coding problem.
• 66885036 doesn't exist; can you check the number?
• a quick scan for OCIDBStartup issues didn't pop up anything open.

[vrogier]

Closing this topic as we continued by email.