Skip to content
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

Add metadata info into DDL #54

Open
no1seman opened this issue Mar 26, 2021 · 2 comments
Open

Add metadata info into DDL #54

no1seman opened this issue Mar 26, 2021 · 2 comments
Labels
Milestone

Comments

@no1seman
Copy link
Contributor

no1seman commented Mar 26, 2021

As for now different tarantool modules or/and applications used it's own mechanisms of manipulating and persisting spaces metadata. Seems that it's time to make single source of truth for the following metadata:

  1. Human readable space name - (string). The main difference from box.space[name] is that human readable space name may contain spaces and even a short description of space contents.
  2. Space description - (string) - Short but exact description of space in a few sentences.
  3. Field description - (string) - Short but exact description of each field of the space in a few sentences.
  4. Field validation rules - (table) - a number of rules to validate space field input data.
  5. Index description - (string) - Short but exact description of index in a few sentences.
@vrogach2020
Copy link

@no1seman would be nice to:
1 understand what features can be unblocked by this issue
2 describe shortly the case when 'Human readable space name' solves a real problem
3 describe format of validation rules and their use cases

@no1seman
Copy link
Contributor Author

@vrogach2020

  1. Spaces and fields metadata is used in many scheme standarts: swagger, json-api, json-schema, GraphQL, avro and so on and so on. What if you need to use in your application not only one of them but for example GraphQL and Swagger? In that case you have to sync schemes by any custom mechanism instead of having one place where to store that info and write universal module that will be compatible with any future ones that lays on suggested API.
  2. It's a common property in all scheme standarts mentioned in previous paragraph.
  3. For example, look into json-schema validation standart: http://json-schema.org/draft/2020-12/json-schema-validation.html The common approach is that we have to have the same validation rules both on Tarantool side and client side: WebUI App, Java driver and so on. If we will store validation rules in one single place in one single format - then we will ba able to reuse them in different cases.

@Totktonada Totktonada added this to the wishlist milestone Oct 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants