[ckan-dev] Datastore dump to CSV url example

Dominik Moritz dominik.moritz at okfn.org
Tue Jun 4 18:55:03 UTC 2013


Hi Henrik,

Thank you for your helpful questions.

On 3 Jun 2013, at 09:33, Henrik Korsgaard <henrikkorsgaard at gmail.com> wrote:

> Hi,
> 
> I have a question/comment regarding the /datastore/dump/{RESOURCE_ID}
> documentation.
> 
> First, It would be nice with an example on how the above url fits in the
> overall urls structure. Is it part of the api/3/action etc., the
> /dataset/package/ etc. or is it appended to the ckan base url? I have tried
> a few combinations but keep hitting a 404.

It goes right behind the ckan url. So you'd have something like `http://ckan.org/datastore/dump/RESOURCE_ID`. I'll make this more clear in the docs. 

However, keep in mind that this feature has been added to CKAN master about a week ago so you may not have it in your CKAN at this point. It will be part of CKAN 2.1.

> 
> What is the preceding path to /datastore/dump/{RESOURCE_ID}?
> 
> Second, the whole 'work-flow' around creating resources - i.e. creating
> datastore resources and providing a dump, i.e. a downloadable version of
> the data in csv file - could, in my opinion, be integrated with the
> 'Download' button on the resource page when it comes to datastore resources
> in the creation process. As it is now, I have to provide an url when using
> the resource_create in the action API, without knowing the final ID or url
> of the resource. Right now I create the resource -> then the datastore
> resource with data (programatically in bulk), and now I am looking into
> changing the url on 100+ resources, so it actually points to a datastore
> dump url.

Totally agreed. It's confusing and many people have asked for clarification in the past. That is why we tried to address this issue with a specification [1] and a number of related issues [2]. The datastore dump feature was one of the features that we needed for this datastore-filestore consolidation. It's still work in progress and we'll not finish this for 2.1. 

For the time being, your process sounds like the best way I could think of.

I'd be really interested in your comments on the specification and the issues. You can respond directly to any issue.

[1] https://github.com/okfn/ckan/wiki/Spec:-DataStore-and-FileStore-Consolidation
[2] https://github.com/okfn/ckan/issues?labels=Datastore+Filestore+consolidation

> 
> Am I approaching this wrongly or do anyone have a good advice on how the
> workflow could be more streamlined?
> 
> -- 
> Med venlig hilsen - Best regards,
> 
> *Henrik Korsgaard*
> Phone: +45 22377114
> Office: CAVI 114b, Aarhus University
> 
> NB. I am slowly migrating my university related correspondence to my
> official AU mail: korsgaard at cavi.au.dk - feel free to contact me at that
> address if relevant.
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev

Dominik Moritz
CKAN developer  |  skype: d.moritz  |  @doobly_doo
The Open Knowledge Foundation
Empowering through Open Knowledge
http://okfn.org/  |  @okfn  |  http://ckan.org  |  @CKANproject





More information about the ckan-dev mailing list