hkdctol
commented
1 year ago This will either be part of cleanup of harvester problems or be irrelevant if we adopt an entirely new approach.
Open jbrown-xentity opened 2 years ago
hkdctol
commented
1 year ago This will either be part of cleanup of harvester problems or be irrelevant if we adopt an entirely new approach.
jbrown-xentity
commented
1 year ago
User Story
In order to have a simple and clean backend, data.gov admins wants all extras_rollup data removed.
Acceptance Criteria
[ACs should be clearly demoable/verifiable whenever possible. Try specifying them using BDD.]
Background
The fact that all extras are stored as
extras_rollupcaused a bug when integrating https://github.com/GSA/ckanext-datajson/pull/115, and required this mind-bending PR that was only able to be tested once integrated with ckanext-geodatagov on catalog: https://github.com/GSA/ckanext-datajson/pull/120.Security Considerations (required)
None
Sketch
We believe the only location of this is in ckanext-geodatagov: https://github.com/GSA/ckanext-geodatagov/search?q=extras_rollup We could consider implementing this in a much cleaner format, by utilizing the IDatasetForm: http://docs.ckan.org/en/2.9/extensions/adding-custom-fields.html. This would require extensive testing however, and evaluating how our other extensions parse data. Essentially I believe this could eliminate "extras", and simplify our responses via API's and make for a cleaner/simpler backend and frontend. It could also be useful in "standardizing" data, such as the fact that we have a "geospatial unique identifier" and a "datajson unique identifier" that are separate. They serve the same function and should/could be combined in CKAN, and it makes it hard for users and us to parse and requires knowing 2 different standards. See datajson example and geospatial example.