Skip to content
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

Support entities #152

Open
16 of 22 tasks
florianm opened this issue Mar 9, 2024 · 8 comments · Fixed by #153
Open
16 of 22 tasks

Support entities #152

florianm opened this issue Mar 9, 2024 · 8 comments · Fixed by #153
Assignees
Labels
feature a feature request or enhancement

Comments

@florianm
Copy link
Collaborator

florianm commented Mar 9, 2024

Feature

Support all API endpoints relevant to entities.

Test data

  • Use the "report a problem" and "address a problem" examples from the entities tutorial
  • Add these two forms as new test forms: use form IDs as defaults, provide env var as overrides
  • Submit some test data
  • Add gate check ru_msg_abort if the given ODKC_VERSION does not support the respective function

https://docs.getodk.org/central-api-dataset-management/

https://docs.getodk.org/central-api-entity-management/

https://docs.getodk.org/central-api-odata-endpoints/#odata-dataset-service

  • service
  • metadata
  • data (link from entity_list man)

Small jobs

  • Adjust Rd documentation: structure with common subheadings, factor out shared text parts. See entity_detail.
  • Extend yell_if_missing to include optionally did (entity list / dataset ID) and eid (entity ID). Update all functions using did or eid.
  • Capitalise Dataset, Entity List, Entity in singular and plural forms.

Discussion points

  • Return format: whatever makes most sense for each endpoint (current implementation but open to suggestions), or always a tibble (near impossible to create predictably without list columns / missing columns), or a custom list of lists (invent an S3 class)?

Approach: return a tibble if possible, keep unstructured = unpredictable data in list columns

@florianm florianm added the feature a feature request or enhancement label Mar 9, 2024
@florianm florianm self-assigned this Mar 9, 2024
florianm added a commit that referenced this issue Mar 9, 2024
* Warn if ODKC version too low
* Modernised parsing of httr::content()
@florianm florianm linked a pull request Mar 9, 2024 that will close this issue
@florianm florianm added this to the ODK Central 2023.3.1 milestone Mar 9, 2024
florianm added a commit that referenced this issue Mar 10, 2024
florianm added a commit that referenced this issue Mar 10, 2024
@roammi
Copy link

roammi commented Mar 14, 2024

thank you @florianm for all the great work for this, I have an use case and I will be looking forward for it to try it out

@florianm
Copy link
Collaborator Author

florianm commented Mar 15, 2024

Oh that's great to hear, @roammi! I'm carving out some time for ruODK, so things are moving forward again.

Do you feel your use case (if appropriate, simplified and de-identified) could be used in a vignette as an example to other ruODK users?

florianm added a commit that referenced this issue Mar 15, 2024
* Downloaded CSV is named after Entity List name
* Support ETag and $filter
* Improve docs, link helpful resources
* Improve submission_export: create local_dir if not exists
* Add tests
@florianm florianm reopened this Mar 15, 2024
@florianm
Copy link
Collaborator Author

Entity Lists are now supported, Entities coming soon.

@roammi
Copy link

roammi commented Mar 15, 2024

Oh that's great to hear, @roammi! I'm carving out some time for ruODK, so things are moving forward again.

Do you feel your use case (if appropriate, simplified and de-identified) could be used in a vignette as an example to other ruODK users?

Yes I do, We will need to put it to work first, but it sounds great, I will be using the update entity function, I'll wait for the new release of ruodk to try it out, or is it a way to try [dataset_update] earlier?

@florianm
Copy link
Collaborator Author

florianm commented Mar 15, 2024

@roammi you can try out entitylist_update right now if you install the latest version of ruODK (see Readme) and update your ODKC_VERSION (see NEWS).

In consultation with the core team ruODK uses the term entitylist for datasets.

Are you saying that you would like to use https://docs.getodk.org/central-api-entity-management/#updating-an-entity ? I will work on that one next then so you can try it out right away.

florianm added a commit that referenced this issue Mar 16, 2024
@roammi
Copy link

roammi commented Mar 28, 2024

@roammi you can try out entitylist_update right now if you install the latest version of ruODK (see Readme) and update your ODKC_VERSION (see NEWS).

In consultation with the core team ruODK uses the term entitylist for datasets.

Are you saying that you would like to use https://docs.getodk.org/central-api-entity-management/#updating-an-entity ? I will work on that one next then so you can try it out right away.

thank you @florianm I have the latest version and it worked succesfully! thank you for the hard work! I've used ruODK::entitylist_list(), ruODK::entitylist_detail() ruODK::entitylist_download()
image

I also used bruno API and test it create, delete and update an entity succesfully so will be great to test it with ruODK. The challenge for update is the baseVersion, you have check the version and increase it by 1 each time making the update, it will be really great to do that natively in ruODK but it could be handled outside in R too

@lognaturel
Copy link

lognaturel commented Apr 1, 2024

The challenge for update is the baseVersion, you have check the version and increase it by 1 each time making the update, it will be really great to do that natively in ruODK but it could be handled outside in R too

You also have the option of using the force query parameter as described in https://docs.getodk.org/central-api-entity-management/#updating-an-entity

If your updates are bringing in values from an external source of truth, it generally makes sense to force the update.

baseVersion exists to detect parallel updates from multiple clients which is especially likely in an offline context. If you’re running a script that is online, it should also generally be appropriate to use the force flag. If your updates are based on the prior version of an entity, you should be able to pull the entity and then update it almost immediately meaning you don’t have to worry about conflicting updates between the two actions unless your context is extremely dynamic.

If you intend to use baseVersion, you shouldn’t have to do any incrementing, you should be able to take the existing value for __version of the entity you want to update and use that as baseVersion for your update. If that’s what you plan on doing, I’d be interested in learning more about what you’re doing with the API and why forcing the update wouldn’t be appropriate for you.

(I’m an ODK maintainer. We can also take this to the ODK forum, sorry about going a bit off topic, @florianm!)

@florianm
Copy link
Collaborator Author

florianm commented Apr 1, 2024

As always, the insight is highly appreciated, @lognaturel!

I'll have to digest the above a bit. Maybe ruODK could default to use the force=true flag.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature a feature request or enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants