search

datopian / ckanext-versioning

Deprecated. See https://github.com/datopian/ckanext-versions. ⏰ CKAN extension providing data versioning (metadata and files) based on git and github.
https://tech.datopian.com/versioning/
GNU Affero General Public License v3.0
7 stars 4 forks source link

Use revision_ref as url parameter #18

Closed pdelboca closed 4 years ago

pdelboca commented 4 years ago

In the last PR I changed to use the tag as a component in the URL, this PR reverses that bad decision to keep using /dataset/xxx/show/{revref}/ as the main url schema.

Note to discuss: The URL schema depends on revision_ref but the UI Rendering depends on tags since all elements that we show like version lists and buttons to edit are tags. This makes it a little bit confusing and we may need to do some refactor to make the whole action methods (and the overall implementation) a little bit easier to understand. Also, we cannot access tag via revision_ref directly in metastore-lib. Even when backend.fetch(...) can receive both tags/revision_ref it does not return the tag metadata (name and description) that we need for the UI.

shevron commented 4 years ago

If I understand correctly this has nothing to do with revision / tag listing BTW, but with showing the dataset in a given tag or revision. I think it would be nice UX if URLs accepted either a tag name or a revision sha regardless if right now we show a list of revisions anywhere in the UI. Then, to make it "just work", we can do one of a few things:

  1. Guess, on the metastore-lib level or ckanext-versioning level, if what we got is a tag or a revision ID. This is better handled by metastore-lib because metastore-lib has that knowledge already and it is backend specific.

Then either:

  1. metastore-lib can expose an API to make that guess, and then ckanext-versioning can call fetch or tag_fetch (IIRC the API) to get the right object, or

  2. metastore-lib can just expose an API to get "revision or tag" given an identifier, without having the calling code having to make that distinction. It will then return either a tag or a revision object and the calling code can check what it got.

rufuspollock commented 4 years ago

@shevron i'm +1 on @shevron point about EITHER revision ref or tag (and that this is probably something metastore lib handles). For now, we can either go with what we got and open an issue to support this later or do this now (if quick and saves us from other issues).

pdelboca commented 4 years ago

Ok, since this will require a little bit of I have opened #20 to implement this.