include_metadata argument not affecting fetch_survey

[joey-levy]

The include_metadata argument doesn't seem to have any effect on the data downloaded with fetch_survey().

This call does not exclude any of the other metadata variables like IP Address for example

dat <- fetch_survey(surveyID =  saved_id, 
                     include_metadata = c("StartDate", "EndDate"))

The above returns the exact same data as

dat <- fetch_survey(surveyID =  saved_id, 
                     include_metadata = NULL)

How would I exclude IP Address (or any other metadata) from a survey data download?

[juliasilge]

Hmmmm, I am not able to reproduce this problem:

library(qualtRics)
res1 <- fetch_survey("SV_3gbwq8aJgqPwQDP", include_metadata = c("Duration", "Finished"), force_request = TRUE)
#>   |                                                                              |                                                                      |   0%  |                                                                              |======================================================================| 100%
#> 
#> ── Column specification ────────────────────────────────────────────────────────
#> cols(
#>   `Duration (in seconds)` = col_double(),
#>   Finished = col_logical(),
#>   Q63 = col_character(),
#>   Q16 = col_character(),
#>   Q17 = col_character(),
#>   Q18 = col_character(),
#>   Q19 = col_character(),
#>   Q22 = col_character(),
#>   SolutionRevision = col_double()
#> )
colnames(res1)
#> [1] "Duration (in seconds)" "Finished"              "Q63"                  
#> [4] "Q16"                   "Q17"                   "Q18"                  
#> [7] "Q19"                   "Q22"                   "SolutionRevision"
res2 <- fetch_survey("SV_3gbwq8aJgqPwQDP", include_metadata = c("StartDate", "EndDate"), force_request = TRUE)
#>   |                                                                              |                                                                      |   0%  |                                                                              |======================================================================| 100%
#> 
#> ── Column specification ────────────────────────────────────────────────────────
#> cols(
#>   StartDate = col_datetime(format = ""),
#>   EndDate = col_datetime(format = ""),
#>   Q63 = col_character(),
#>   Q16 = col_character(),
#>   Q17 = col_character(),
#>   Q18 = col_character(),
#>   Q19 = col_character(),
#>   Q22 = col_character(),
#>   SolutionRevision = col_double()
#> )
colnames(res2)
#> [1] "StartDate"        "EndDate"          "Q63"              "Q16"             
#> [5] "Q17"              "Q18"              "Q19"              "Q22"             
#> [9] "SolutionRevision"

^{Created on 2022-12-05 with reprex v2.0.2}

Can you create a reprex (a minimal reproducible example) for this? The goal of a reprex is to make it easier for us to recreate your problem so that we can understand it and/or fix it. If you've never heard of a reprex before, you may want to start with the tidyverse.org help page. You can censor any PII with "xxx" in the output if needed. Thanks! 🙌

[jmobrien]

@joey-levy, you may know this--but just to make sure, I thought I'd draw your attention to where @juliasilge's code has the argument force_request = TRUE appended.

The default is FALSE--meaning that if you call fetch_survey([survey_id]) once (without include_metadata, implying that you keep everything), subsequent calls to fetch_survey() in the same R session will just re-load the previously cached version instead of querying the API. (You see a message about this.) Adjustments to the parameters of the API query thus won't do anything, because no query is actually made.

[joey-levy]

@juliasilge thanks for taking the time to test this out! While working on a reprex, @jmobrien solved my oversight. That's exactly what I was doing wrong. I also had verbose set to FALSE in my session so I missed exactly this message that would have shared the answer. Apologies for a false alarm on this question! Thanks for making and maintaining such a useful package!

[jmobrien]

Thanks for the follow-up @joey-levy. We're already discussing whether the caching feature, though long a part of the package, is really what users expect or want. We're both leaning towards changing that default behavior; this is perhaps further evidence that doing so would be the right choice.