Skip to content

feat: introduce structure between products, TEA components, collections #119

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

taleodor
Copy link

This commit switches to

/product/1234-1234-1244-124324

/products

/tea-component/1234-1234-1244-124324/collections

notations as discussed on the call on 2025-04-16.

Basic linting is also included.

This commit switches to

/product/1234-1234-1244-124324

/products

/tea-component/1234-1234-1244-124324/collections

notations as discussed on the call on 2025-04-16.

Basic linting is also included.

Signed-off-by: Pavel Shukhman <pavel@reliza.io>
@taleodor taleodor requested review from oej and madpah as code owners April 17, 2025 18:15
@@ -17,85 +15,126 @@ servers:
- url: http://localhost/tea/v1
description: Local development
paths:
/product/uuid/{uuid}:
/product/{uuid}:
get:
description: Returns the corresponding leafs for a given product UUID.
operationId: getTeaProductByUuid
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is not part of the PR, but do we need Tea in the name of each operation?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really know, don't think so.

Comment on lines 90 to +97
parameters:
- $ref: "#/components/parameters/leaf-identifier"
- name: uuid
in: path
required: true
description: UUID of TEA Component in the TEA server
schema:
type: string
format: uuid
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't we need additional pagination parameters?

As remarked in one of the workshops, there can be hundreds of collections per component.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I agree, but I think we should add to later PRs - there are other issues here to discuss as well.

oej and others added 2 commits April 28, 2025 15:01
Co-authored-by: Piotr P. Karwasz <piotr@github.copernik.eu>
Signed-off-by: Olle E. Johansson <oej@edvina.net>
Co-authored-by: Piotr P. Karwasz <piotr@github.copernik.eu>
Signed-off-by: Olle E. Johansson <oej@edvina.net>
@@ -176,7 +215,7 @@ components:
required:
- identifier
- product_name
tea_leaf:
tea_collections_list_view:
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tea_leaf was replaced by components - not collections. Is this really right?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is what I wanted to discuss. It is currently unclear to me how to define this properly. In other words, what is the difference in terms of underlying object properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants