+1
Really like the fact that you're also considering multilingual support!

Keeping the JSON format simple is also a good way to balance usability/i18n, and DB tools like PgAdmin, Toad, Navicat, etc. all will show the comments natively.

For the default language, your format is simple enough:

{ "label": "Books" }

When supporting other languages, will it be something similar to ckanext-fluent?

{ "label": { "en": "Books", "fr": "Livres" } }

I intentionally made the JSON just one line. After doing some quick tests with several postgres UI tools, I found that they assumed the comment was on one line...

I might follow the pattern set out by the get_translated helper in CKAN. If there's a field called "label_translated" then it will have each language version, if not gettext is used on the "label" field to get a label for the user. This would cover both common use cases (central translation tables vs. per-column translations) and templates and API clients won't need to do any type checking.

👍

This PR needs tests for the API changes, tests for the controller and a way to display the labels and description fields to users without edit access

Can confirm it works. Comments show up in postgres tools too like Navicat, psql, Toad, etc!

It'd be interesting to see how regular users can see the column info. Should it be implemented as a default Resource View?

Maybe these fields should be returned from datastore_info instead of datastore_search

Sadly I can't use datastore_info because it doesn't seem possible to extend, and it returns less information than the "fields" list returned with every datastore_search

@wardi regarding how this will play with the DataPusher you are right in that the DataPusher will remove the table before each run but it would also be easy to retreive the current info before and resubmit it (we are already calling datastore_search on the resource table before deleting). The question is if that would be intended behaviour as you might get whatever information you have there (field types, field labels...) out of sync with the new data.

for datapusher the field types shouldn't be preserved, just the value of the "info" field (currently "label" and "notes" but some sites may extend that however they see fit)

Great stuff @wardi

Hi,

I was exploring the use of the Data Dictionary on the dataset level when I chanced upon this.

Being a beginner at CKAN, may I know the prerequisites for using this plugin and if there are screenshots of the output, may I see it?

Thank you in advance!

@JerlynPeh this one is a feature of the datastore plugin which is part of the ckan repository, so you either wait for our next release (you can run master for development) or backport the feature to the version of ckan you're running.

@wardi Thanks for your response! How do I go about backporting this feature?

What I did is to copy the changes in the codes according to the commits for this feature into my version of CKAN. However, even after restarting the server and CKAN, there is no visible difference and there isn't any error with running the codes.

What would you advise to do from here?

What would be the correct way to expand this ?
I want to add an extra field to the form and keep some extra information along with description and label

All you need to do is add your field to the template and it should get saved.

Works good,
Would recommend to add blocks in dictionary.html and resource_read.html so we can just expand it with super() without needing to almost override your file.

@ggcatu good idea, PR welcome!

#3751

I also added a question there.

Any idea on how should I proceed so that any changes made in the dictionary are reflected on the Activity stream of the org? Can't seem to find any documentation on this, would preffear asking before smashing my head against the code

@TkTech something for extended activities?