[ckan-dev] FIxing the DataStore vs FileStore duality confusion

Sean Hammond sean.hammond at okfn.org
Fri Mar 15 12:42:17 UTC 2013


> By the way, I admit my user stories covered functionality beyond the
> basic datastore/filestore - I included them because I think they all
> nevertheless bear on what kind of behaviour users will expect from
> CKAN's storage, and in all cases, this is that the user just wants to
> know 'Have you got the data or not?' not 'Have you got it in your pink
> folder? How about your purple folder?' So I agree that the 'suggested
> behaviour' is far too complicated and confusing (and so is the current
> behaviour).

I think the functionality implied by these user stories sounds really
great though, if we ever decide to implement those features, they take
CKAN closer to being the "github of open data". With the 'alternative
suggestion' on the wiki page, I think space is still left to implement
this sort of thing (whereas with the original suggestion, when the
datastore was read-only except for special datastore resources, I was a bit
worried that we were closing off future development).

There are some pain points with the alternative suggested behaviour:

- Need for separate 'download' and 'download original file' buttons,
  will users understand the difference/can we present it clearly?

- Need for warning messages when uploading a new copy of a file: this
  will overwrite the previously uploaded file and (if the data has been
  edited in the datastore) the modified data in CKAN - will this warning
  confuse users?

> One comment: I appreciate that datastore versioning, nice though it
> might be, is a long way off. But how feasible is it to at least keep a
> list of edit time + user for each (editable) datastore resource?

I haven't looked at how the datastore works internally but I would guess
this would be quite easy.




More information about the ckan-dev mailing list