Add context (res id and name) when downloading data

[Moohan]

The problem was highlighted in this teams chat, when using get_dataset if the dataset doesn't include a variable like date it becomes impossible to tell which rows are from which resource as get_dataset just joins them into a single tibble.

This PR introduces an include_context parameter which is FALSE by default to both get_resource and get_dataset if TRUE they will now append a few variables: "res_id", "res_name", "res_created_date" and "res_modified_date" to the front of the data.

For get_dataset this is achieved with no additional API calls as all the needed info is included when we hit package_show for the list of IDs. For get_resource this involves an additional API call to resource_show (we haven't used this before).

I chose to have them both be FALSE by default so it won't break any existing code.

[csillasch]

This is great! I`m probably leaning toward having it optional (but perhaps default to TRUE for get_dataset) and I think it might be worth having the option for get_resource as well (but would perhaps default to FALSE for get_resource)?

[Moohan]

From discussion

• Add some more tests with other datasets and resources (d3eaaf84-0f3b-4fb8-9460-e33503095fbe).
• Should missing modified date be created date.
• Parse the dates as a date
• Deal with dump extract

[Moohan]

@csillasch and @ross-hull I think this is done now.

The modified date still returns as NA if nothing is returned from the API (we discussed possibly setting it to the created date but don't remember the final decision?

We talked about adding some additional tests, I've added some but please let me know if you want anything else specifically testing - or importantly if you find a resource / dataset this isn't working for in which case I'll definitely add that and fix whatever the issue is!

[ross-hull]

This looks good to me. And using it as a user was simple. One thing that I wondered is if it is worth having the same naming convention between the new context columns, as is already used in the open data? The context columns are snake case while the others are upper camel.

[csillasch]

Looks good!

I spotted unexpected behaviour when testing on the General Practitioner Contact Details dataset: modified date is returned correctly using get_dataset but returns NULL with get_resource("647b256e-4a03-4963-8402-bf559c9e2fff")

Suggested a change to sort this which works for the resource but might be worth testing against some of the others - especially where it worked fine previously.

[Moohan]

This looks good to me. And using it as a user was simple. One thing that I wondered is if it is worth having the same naming convention between the new context columns, as is already used in the open data? The context columns are snake case while the others are upper camel.

Fair enough, do these names look good?

"ResId" (or "ResID"?)
"ResName"
"ResCreatedDate"
"ResModifiedDate"

[csillasch]

Get_dataset seems to handle it fine but get_resource is returning the dates as lists - all your changes look OK to me so not sure how/why this is happening