Closed the-mad-statter closed 1 year ago
@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 has_repeating_instruments_or_events
is referenced, the code checks to see if it exists. If it doesn't exist, throw an error (with stop()
) that their version of REDCap apparently doesn't support repeated instruments/events.
I can add the stop()
, but it's not that v7 REDCap doesn't support repeated instruments/events but that the API neglects to report on it via the project info endpoint.
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 has_repeating_instruments_or_events
value should have been had the API reported on it and set it as appropriate.
it's not that v7 REDCap doesn't support repeated instruments/events but that the API neglects to report on it via the project info endpoint.
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.
As a work around consider the idea to read a single record and check the returned field names...
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 stop()
for a PR and call it a day. Should I use main or dev?
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.