You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, thanks for the great wrapper library!
However, there is a small issue with Object::get_by_attr method: when using FLOAT data type, a call to dpiObject_getAttributeValue results in a segfault, because internally ODPI-C library treats FLOAT as a subtype of NUMBER and expects a buffer in asBytes.ptr, which is currently set only when the attr.oratype is OracleType::Number (.. which corresponds to NUMBER, but not to FLOAT).
I am unsure whether it is a bug in oracle's documentation of dpiObject_getAttributeValue which only mentions DPI_ORACLE_TYPE_NUMBER or not, but nevertheless is seems like we need to utilize dpiData_setBytes also for attr.oratype being OracleType::Number.
We made a local circumvention by migrating from FLOAT to NUMBER in our database, so unfortunately we can't test whether adding a simple if condition for OracleType::Float would work, hence we are not providing a PR, sorry :(
The text was updated successfully, but these errors were encountered:
Thanks for your reporting the issue.
It isn't a bug in the document of dpiObject_getAttributeValue. It is a bug in rust-oracle.
Rust-oracle distinguishes NUMBER and FLOAT. On the other hand ODPI treats both as DPI_ORACLE_TYPE_NUMBER.
Dear Kubo-san,
First of all, thanks for the great wrapper library!
However, there is a small issue with Object::get_by_attr method: when using FLOAT data type, a call to dpiObject_getAttributeValue results in a segfault, because internally ODPI-C library treats FLOAT as a subtype of NUMBER and expects a buffer in asBytes.ptr, which is currently set only when the attr.oratype is OracleType::Number (.. which corresponds to NUMBER, but not to FLOAT).
I am unsure whether it is a bug in oracle's documentation of dpiObject_getAttributeValue which only mentions DPI_ORACLE_TYPE_NUMBER or not, but nevertheless is seems like we need to utilize dpiData_setBytes also for attr.oratype being OracleType::Number.
We made a local circumvention by migrating from
FLOAT
toNUMBER
in our database, so unfortunately we can't test whether adding a simpleif
condition forOracleType::Float
would work, hence we are not providing a PR, sorry :(The text was updated successfully, but these errors were encountered: