-
Notifications
You must be signed in to change notification settings - Fork 48
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
Unexpected Behavior: redcap_read()
fails for older versions of REDCap (~v7.3.5)
#465
Comments
@the-mad-statter, I like that idea and would love that PR. Even if I wasn't interested in supporting v7 (and honestly, I'm only lukewarm about it), I really like the idea of gracefully growing. Please make sure that before |
I can add the As a work around consider the idea to read a single record and check the returned field names for either "redcap_repeat_instrument" or "redcap_repeat_instance" to determine what the |
I understand your distinction now. But I think I'm okay lumping those two cases together for a version that was released 4+ years ago.
I'll try to be flexible, but in my experience, that strategy makes things less stable. I prefer to use explicitly declared values to detect the server's capabilities. If I go the indirect/infer approach, I'm worried about not accounting for all the possible corner cases. |
Sure thing, I don't particularly like the work around either. Therefore, I will add the |
Slightly prefer pulling into dev, but I can work with either. Hope things are good in St. Louis. Tell me if you're ever back in Oklahoma. |
I am not sure if you want to support this given that it effects pretty old versions of REDCap, and I am not sure when Vanderbilt fixed the root cause, but
redcap_read()
presently fails when trying to read records on older versions of REDCap circa v7.3.5.Specifically, I am trying to read data from a v7.3.5 instance of REDCap, and
redcap_read()
fails with the following:I have traced the issue to a pairing of what the REDCap API returns and this commit on 2022-10-08. That is,
redcap_read()
broke for v7.3.5 with this commit.The underlying issue is that
redcap_metadata_internal()
expects a long list of columns to be returned, but the API does not return all of them for older versions of the API.Here are the expected columns:
Created on 2023-02-03 with reprex v2.0.2
And here are the actual columns returned:
Created on 2023-02-03 with reprex v2.0.2
A
setdiff()
would show the missing columns are those listed in the part of the message produced byread_csv()
:The actual stopping error happens later in
redcap_metadata_internal()
when there is an attempt to checkd_proj$has_repeating_instruments_or_events[1]
which isNULL
on account of not having been returned by the API.I have a solution that produces the expected
d_proj
object withNA
for the missing columns, but before I initiated a pull request, I wanted to see if this was something you wanted to support.The text was updated successfully, but these errors were encountered: