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

[Ian Ward]

On Thu, Nov 7, 2013 at 3:11 PM, Konrad Reiche <konrad.reiche at gmail.com> wrote:
> 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}" }

Yes, extras are stored as string values in an "extras" database table,
so if you pass other types of objects they get converted into strings
before they are stored.

Extras on resources are different, though. They get stored together in
a single JSON string in the resource, so I'm not sure if they maintain
nested values or not.

> 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.

Validation of dataset and resource fields is done with an IDatasetForm
plugin using python code. What sort of validation are you looking for?

Ian