Old queries failing with v1.2.0

[aimran]

Since I upgraded to v1.2.0 I am beginning to see lots of error messages like this

Error in .json.tabular.to.data.frame(response.content[["columns"]], c("character", : Unexpected data class: NULL

These are results from running dbGetQuery. Oddly, the same queries were working in the previous version I had (1.0.0). Even more oddly, I had to find a hacky work around involving a timeout! So, instead of running dbGetQuery(conn, statement), I am doing the following:

presto_query <- function(conn, statement, t=2) {
  res <- dbSendQuery(conn,statement)  
  Sys.sleep(t)  
  data <- dbFetch(res)  
  data  
}

Any ideas on how I could go about debugging it. FYI, I also tried installing RPresto directly from the repo without any luck.

sessionInfo(package = 'RPresto')
R version 3.2.4 Revised (2016-03-16 r70336)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.3 LTS

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8       
 [4] LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C              
[10] LC_TELEPHONE=C             LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
character(0)

other attached packages:
[1] RPresto_1.2.0

loaded via a namespace (and not attached):
 [1] httr_1.1.0      magrittr_1.5    R6_2.1.2        assertthat_0.1  graphics_3.2.4  parallel_3.2.4 
 [7] DBI_0.3.1       tools_3.2.4     dplyr_0.4.3     utils_3.2.4     curl_0.9.6      yaml_2.1.13    
[13] grDevices_3.2.4 Rcpp_0.12.3     stats_3.2.4     datasets_3.2.4  methods_3.2.4   jsonlite_0.9.19
[19] base_3.2.4      RPostgreSQL_0.4

[onurfiliz]

@aimran thank you for the excellent bug report and apologies for the errors. It stems from a wrong assumption on my part about possible presto responses. Could you try with:

devtools::install_github('prestodb/RPresto', ref='robustness_fixes')

and see if the issues are resolved?

[aimran]

@onurfiliz Thanks for your kind words — y'all make our work very easy!

This is to confirm that the robustness_fixes branch indeed fixes the issue on my end. I put the (failing) queries through its paces and it is returning without errors.

Thanks so much for the quick turn around on this.