[ckan-dev] What is the current state and future of the extras field?

[Konrad Reiche]

Hey there,

what is the current state of the extras field in CKAN packages? As far
as I have learned subfields should be kept flat, without additional
nesting. If nested, then the nested fields need to be serialized to strings.

"extras": { "my_field": { "my_subfield": 122 } }

becomes

"extras": { "my_field": "{\"my_subfield\": 122}" }

Is this still correct or should nested fields be avoided altogether? If
I recall right the decision was made for better compatibility with the
interface when editing packages.

Also the different presentations of the Model API (/rest) and the Action
API (/action) confused me a bit:

/api/rest/dataset/...
extras: { links:stw: "13.675", triples: "100.720.519" }

/api/action/package_show?id=...

extras: [{
state: "active",
value: ""13.675"",
revision_timestamp: "2013-07-03T11:54:33.733378",
package_id: "619d4224-7388-4564-863f-f83bac46a2a7",
key: "links:stw",
revision_id: "e68c957b-0d1c-4dde-8aa7-71cb41a4499a",
id: "66c4670d-495a-4df5-aea4-e72feedbb639"
},
{
state: "active",
value: ""100.720.519"",
revision_timestamp: "2013-07-03T11:54:33.733378",
package_id: "619d4224-7388-4564-863f-f83bac46a2a7",
key: "triples",
revision_id: "e68c957b-0d1c-4dde-8aa7-71cb41a4499a",
id: "82189fd3-a2f0-4691-bf88-f5d8acd4b33d"
}]

Obviously, the Action API carries more information and aggregates it
from different tables. The same difference can be seen on tags, groups.

I am bringing this up, because this kind of presentation seems to
suggest, that nested field should rather be avoid altogether, or
shouldn't they?

Also asking, because I am looking for further methods to validate CKAN
packages against a JSON schema and I wonder if it would be better to
define extras as an array of objects or as an object as it was before in
the Model API. Since, Model and Search API are deprecated I guess the
former case.

Yet I want to know where this is heading. Looking forward for every comment.

Best,
Konrad