Features requests!
#256
Replies: 1 comment 1 reply
-
|
JSON would be great. Particularly supporting the new internal storage format that DB 21c can use. Our SODA team would also no doubt love to see SODA support. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Perhaps supporting opentelemetry when this is GA? Support for traces would be wonderful! :) Some kind of trace functionality that captures all ocilib calls (and possibly the data in/out) for debugging (and reducing large test cases) issues with ocilib? :) |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hello all,
I would like to know what features you would like see added to OCILIB for C and C++ APIs
I was planning to work on the JSON support in recent Oracle DB versions and adding a OCI_Json datatype to the C API and ocilib::Json to the C++ API.
I am also considering to upgrade the C++ API to C++17 but I need more information about current C++ standard target version used by OCILIB C++ applications (if most of them still uses pre C++11, it might not worth it).
I also had in mind for a while to support multiple OCI clients within same running application by making OCI_Initialize() being replaced by OCI_EnvironmentCreate() but I not sure how the ROI of such major API changes.
One major thing that I am also thinking is to reduce the number to OCILIB API symbols. From day one, the design was to not expose any data structure, being type safe (not playing around whit passing user different datatypes through void buffers) .This resulted in having hundreds of dedicated methods for handling types for fetching, bindings, settter/getters and so on.
Thus, I am still working of finding a way to keep simple contracts while trying to reduce the number of symbols.
Another area is that OCILIB 1.0, back in 2007, started small and over the years, symbol naming became not very consistent and not using a common pattern.
If you have any inputs on API changes to simplify workflows, make them more natural or any changes that reduce application required code to implement workflows, let me know :)
Regards
Vincent
Beta Was this translation helpful? Give feedback.
All reactions