Support new Datatypes
New Datatypes to be added
- [ ] Decimals
- [ ] IPv4
Enhancements
- [ ] improve templating design
- [ ] add option to create nullable columns by default
There is also missing support for IPv4. Just stumbled upon this type in my CH database and RClickhouse refused to select it...
There is also missing support for IPv4. Just stumbled upon this type in my CH database and RClickhouse refused to select it...
@Lupus thank you very much for your suggestion, it has been added to the todos
Can you add support for u\int128, u\int256? And custom mapping Array to vector with padding (if the array is of variable length)?
Since R does not directly support bigger integer values, u\int128 and u\int256 are not that easy to implement. We would have to rely on additional packages. We'll re-evaluate existing packages and check if it is feasible.
There still seems to be some problems with decimals for me:
> t_sale_details <- tbl(con, "T_SALE_D")
Error in `dplyr::db_query_fields()`:
! Can't query fields.
Caused by error in `fetch()`:
! cannot read unsupported type: Decimal(18,6)
Indeed, Decimals, especially those with custom precision, are not yet supported. There is no native R type that would fit reasonably well, but there are some third-party packages. Suppose your analyses heavily rely on these data types. In that case, I recommend doing most of these calculations directly in SQL and using other data types (e.g., floats) if possible. In the long run, we'll add support based on third-party packages.
Indeed, Decimals, especially those with custom precision, are not yet supported. There is no native R type that would fit reasonably well, but there are some third-party packages. Suppose your analyses heavily rely on these data types. In that case, I recommend doing most of these calculations directly in SQL and using other data types (e.g., floats) if possible. In the long run, we'll add support based on third-party packages.
Thanks for your reply! Due to permission issues, I can't modify the data type directly. Doing calculations directly in SQL is a feasible approach. But luckily, I have tried another solution that might be better, ODBC, which means you may need to install the ODBC driver first. For more specific details, see the Posit Solutions. Hope this helps people who have the same difficulties as me. : )