search

tarantool / ddl

The DDL module enables you to describe data schema in a declarative YAML-based format.
BSD 2-Clause "Simplified" License
12 stars 6 forks source link

Add metadata info into DDL #54

Open no1seman opened 3 years ago

no1seman commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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.