- Issue created by @paul121
- @paul121 opened merge request.
- Status changed to Fixed
8 months ago 12:02am 27 October 2023 Automatically closed - issue fixed for 2 weeks with no activity.
We will run into an issue where JD organizations will have lots of data and it is simply too much to query + display on each page load in farmOS. A notable issue are field operations - these can only be queried at a URL path that includes the Field ID, a separate request for each field. This makes it hard to display all field operations for all fields on the same page (100s of fields with dozens+ of operations each).
We also need a way to keep track of which JD data we have already imported, and keep track of both new + modifications to JD data.
The JD eTag system could work really well for this: https://developer.deere.com/dev-docs/field-operations#eTags
This allows requests for common "lists" of data to only return new + modified values. It works by keeping track of a "signature" for each API list and passing it as a header when making subsequent requests. If there are changes, then a new signature is included in the response for use later on.
We could combine eTags with new database tables to serve as a caching layer for new + modified JD data. The existing import forms can be updated to read from this cache table instead of directly querying the JD API on demand. We can provide buttons/forms to "refresh" the changes with JD and also do this quite easily via a CRON job. A final really nice benefit of this is that we could incorporate these custom database tables with views and provide additional sorting/filtering options, as well as an easy way to join in asset/relationships to display in the table alongside JD data.
N/A
Create custom database tables to cache JD data requested with eTags
Implement
Additional UI for syncing/refreshing changes from JD
None
New database tables to store these updated/pending changes
Fixed
1.0
Code
Automatically closed - issue fixed for 2 weeks with no activity.