Hi Steven,
I managed to figure this one out a few months ago after looking at the registry source code and changelog. There was a change in how the ‘extras’ were handled.
There had been attributes we had to submit within an “extras” hash because the registry did not autoconvert them. Many (at least all of the ones I’ve been using) are now accounted for, so rather than this:
{
filetype: "activity",
owner_org: "ia_nam",
...,
extras: {
iati_version: "2.1",
data_updated: "2018-01-01",
activity_count: 5
}
}
we now have to reposition those extras because they are now accounted for in the schema by auto-conversion. So adding them explicitly creates a conflict. So, now I do:
{
filetype: "activity",
owner_org: "ia_nam",
...,
iati_version: "2.1",
data_updated: "2018-01-01",
activity_count: 5
}
without specifying extras, as they are now explicitly auto-converted by the registry.
The above works great if you’re adding brand new packages. However, I found out that updating existing packages that were submitted the old way (with an “extras” hash in our code) may fail if you just patch the fields like the CKAN docs recommend: running package_search or package_show and then calling package_update on the result with new data. The problem is that the old extras hang around, so what I did was make sure to add a line to delete the “extras” hash from my package_show/search result before patching with package_update. Then there’s no conflict to throw the schema error.
Happy to send a code snippet if needed. Hope this helps!
