-
Notifications
You must be signed in to change notification settings - Fork 78
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OCINumber as a native type #4
Comments
There is no plan to expose OCINumber as a native type but that can be considered. ODPI-C currently performs the conversion for you automatically from OCINumber to integer, double or string depending on the value of dpiNativeTypeNum that you select when creating the variable. This is either known in advance (and explicitly specified) or can be determined by examining the metadata. In any case, that is what the drivers that I have migrated to use ODPI-C currently do. This reduces the number of calls that need to be made since the conversion happens internally during the fetch. Do you have a particular driver in mind? |
This comment was edited. I'm now writing a Rust driver. // This API isn't fixed. I bet that it will be changed later.
let stmt = conn.prepare("select number_col form some_table");
// The number_col must be defined explicitly. Otherwise, ODPI-C defines it as double implicitly.
// The driver cannot guess what method is called later to get the column data.
stmt.define(1, oracle::NativeType::Integer);
stmt.execute();
let row = stmt.fetch();
row.get::<i64>(1); // Get the first column as 64 bit integer. If OCINumber is exposed as a native type, the code become a bit simple as follows. let stmt = conn.execute("select col form some_table"); // No need to define the number column as integer.
let row = stmt.fetch();
row.get::<i64>(1); // The driver converts OCINumber to 64 bit integer internally. I won't permit |
Why can't you examine the metadata in your driver? If the scale is zero and the precision is a positive number less than or equal to DPI_MAX_INT64_PRECISION, the value can be converted to a 64-bit integer. If the scale is zero and the precision is greater than DPI_MAX_INT64_PRECISION it can be converted to a big integer (via string). For all other cases double makes the most sense. I'm not sure what the advantage would be to force the end user to make that decision instead? My suggestion would be to use the above heuristic as a default and allow the end user to override that only if they need to do so -- and most of the time that should not be necessary. The method row.get() should then simply return the correct type without having to specify |
End users must decide the type returned by Example of type inference: let col_data = row.get(1);
... pass col_data to an i64 argument of a function ... The |
I don't request you to change the default native type of number to OCINumber. I agree that double is preferable in general. However it is not preferable for my driver. |
The default native type is changed to integer if it the number can be placed in a 64-bit integer and is otherwise returned as double. You can adjust this to return integer, double or text as needed. This is all that OCI supports and should be sufficient for your needs, too. Feel free to reopen this discussion if desired. |
Would you have a plan to expose OCINumber as a native type?
It is required for drivers which implement JDBC-like API.
Assume the following code:
The native type of
NUMBER_COL
is not decided atstmt.executeQuery()
. It depends on methods such asgetInt
after the column data is fetched. However such API cannot be implemented by ODPI-C, which must declare native types explicitly or implicitly at SQL execution time.If ODPI-C exposes OCINumber as a native type and provides conversion functions between OCINumber and integer, double and text, drivers can convert the OCINumber to int, long, double and BigDecimal via text after it is fetched.
The text was updated successfully, but these errors were encountered: