Add Date, POSIXct and hms types - #333
Conversation
|
Thanks for looking into it. Is there a timeline for BH 1.75? Can we keep |
|
BH will be updated in the beginning of January. Some depending packages needed to be updated first.
I hoped extended_types would be set to true, but I understand your concerns. You can go ahead and change it, I will not have access to my computer for the next few weeks.
… Sent: Tuesday, December 22, 2020 at 6:49 PM
From: "Kirill Müller" ***@***.***>
To: "r-dbi/RSQLite" ***@***.***>
Cc: "anderic1" ***@***.***>, "Author" ***@***.***>
Subject: Re: [r-dbi/RSQLite] Add Date, POSIXct and hms types (#333)
Thanks for looking into it. Is there a timeline for BH 1.75?
Can we keep `extended_types = FALSE` for now?
--
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#333 (comment)
|
| pkgconfig, | ||
| Rcpp (>= 0.12.7) | ||
| Rcpp (>= 0.12.7), | ||
| hms |
There was a problem hiding this comment.
I'm a bit hesitant to bring in hms as a dependency here. Can we move to Suggests and load only if a connection with extended types is requested?
| if (with_alt_types) { | ||
| DATA_TYPE decl_dt = get_decl_data_type(); | ||
| if (decl_dt == DT_DATE || decl_dt == DT_DATETIME || decl_dt == DT_TIME) { | ||
| return decl_dt; |
There was a problem hiding this comment.
Does this mean that a declared data type overrides what's stored in the columns?
| } | ||
| return dateval; | ||
| } else { | ||
| return static_cast<double>(sqlite3_column_int(get_stmt(), get_j())); |
There was a problem hiding this comment.
What happens if the underlying data is an integer or a blob?
|
When done, we can enable many more DBItest tests that test for roundtrip for these data types. |
|
Replies inline
Sent: Sunday, December 27, 2020 at 10:27 AM
From: "Kirill Müller" ***@***.***>
To: "r-dbi/RSQLite" ***@***.***>
Cc: "anderic1" ***@***.***>, "Author" ***@***.***>
Subject: Re: [r-dbi/RSQLite] Add Date, POSIXct and hms types (#333)
@krlmlr commented on this pull request.
Thanks, I took a closer look.
Is the implementation in line with the discussion in #237?
I would say so, insofar as if the flag is not set everything will be like before. If (1) flag is set and (2) column is declared exactly modulo case, as 'date': a number will be interpreted as count of days since 1970-01-01, with class attribute 'Date' attached to it, ie an R date, and an iso string ('yyyy-mm-dd') will be converted to an R date. Everything else will return NA. Similarly for 'datetime'/'timestamp' -> POSIXct (UTC), and 'time' -> hms/difftime (unit=seconds).
> @@ -164,7 +165,20 @@ List SqliteResultImpl::get_column_info() {
CharacterVector types(cache.ncols_);
for (size_t i = 0; i < cache.ncols_; i++) {
- types[i] = Rf_type2char(DbColumnStorage::sexptype_from_datatype(types_[i]));
+ switch(types_[i]) {
+ case DT_DATE:
+ types[i] = "Date";
+ break;
+ case DT_DATETIME:
+ types[i] = "POSIXct";
+ break;
+ case DT_TIME:
+ types[i] = "hms";
This needs to be the equivalent of `c("hms", "difftime")` .
Yes I was unsure about this one. POSIXct should similarly be c(POSIXct, POSIXt). Then the column should be a list column(?), but this also makes it harder to use. That's why I opted for a single element.
> @@ -43,14 +43,15 @@ Imports:
memoise,
methods,
pkgconfig,
- Rcpp (>= 0.12.7)
+ Rcpp (>= 0.12.7),
+ hms
I'm a bit hesitant to bring in hms as a dependency here. Can we move to Suggests and load only if a connection with extended types is requested?
I brought it in because as the existing code was written, at one moment the c++ code calls new_hms() from the hms package on the column. This could of course be changed, then hms can be moved to suggests.
> {
}
DATA_TYPE SqliteColumnDataSource::get_data_type() const {
+
+ if (with_alt_types) {
+ DATA_TYPE decl_dt = get_decl_data_type();
+ if (decl_dt == DT_DATE || decl_dt == DT_DATETIME || decl_dt == DT_TIME) {
+ return decl_dt;
Does this mean that a declared data type overrides what's stored in the columns?
Yes, but again only for the aforementioned column types, and if the flag is set. If the value cannot be converted NA is returned. If the flag is not set everything works like before.
> + int dt = get_column_type();
+
+ if (dt == SQLITE_TEXT) {
+ const char* dtstr = reinterpret_cast<const char*>(sqlite3_column_text(get_stmt(), get_j()));
+ double dateval;
+
+ try {
+ bg::date dt(bg::from_simple_string(dtstr));
+ bg::date_duration delta = dt - bg::date(1970, 1, 1);
+ dateval = static_cast<double>(delta.days());
+ } catch (...) {
+ dateval = NA_REAL;
+ }
+ return dateval;
+ } else {
+ return static_cast<double>(sqlite3_column_int(get_stmt(), get_j()));
What happens if the underlying data is an integer or a blob?
Integer works as expected. Blob however i have not tested. This is an oversight, my guess is that it will return 0 (ie 1970-01-01). A better option imo would be to return NA in this case.
… --
You are receiving this because you authored the thread.
Reply to this email directly or view it on GitHub:
#333 (review)
|
|
I addressed all but one of the issues you mentioned and added warnings when blobs are encountered. I did not yet address the columninfo for time columns. As I mentioned earlier, how should this be returned? Should the whole column be coerced into a list column? Or perhaps add a third column as you alluded to in the beginning? For simplicity I think keeping just |
|
Thanks. Could you please rerun (e.g. merge with master) when BH 1.75 becomes available on CRAN? The class needs to be |
|
One last thing, would you mind if I changed the default value of extended_types to something like |
|
BH has been updated on cran. |
krlmlr
left a comment
There was a problem hiding this comment.
Thanks, looks good. Just a few minor tweaks necessary.
Co-authored-by: Kirill Müller <krlmlr@users.noreply.github.com>
Co-authored-by: Kirill Müller <krlmlr@users.noreply.github.com>
|
I think we are done here. I committed your suggestions and you are right, it is better to be too strict and then loosen up than the other way around. |
|
Thanks! |
Following #319 this PR adds support for Date, datetime and hms types. It depends on BH package version 1.75.0-0 which is not yet on CRAN.
The new option
extended_typesis set toTRUEby default in thedbConnect()method but could be set toFALSEto return to the old behaviour.