ColumnConfig DataTypeEnum #2

New Issue

Daniel_Hassert · 2024-06-10T10:57:35+02:00

Daniel_Hassert commented

2024-06-10 10:57:35 +02:00

DataTypeEnum wirklich mit beginnenden Großbuchstaben?

ColumnConfig:
    type: "object"
    required:
        - "Guid"
    properties:
        Guid:
            type: "string"
        Columns:
            type: "array"
            items:
                type: "object"
                required:
                    - "Designation"
                    - "DataType"
                    - "FieldName"
                properties:
                    Designation:
                        type: "string"
                    DataType:
                        type: "string"
                        enum:
                            - "String"
                            - "Integer"
                            - "Decimal"
                            - "Boolean"
                            - "Date"
                            - "DateTime"
                    FieldName:
                        type: "string"

Vielleicht besser

DataType:
  type: "string"
  enum:
      - "string"
      - "number"
      - "boolean"
      - "date"
      - "dateTime"

Data Types Spec

Primitive data types in the OAS are based on the types supported by the JSON Schema Specification Wright Draft 00.
Note that integer as a type is also supported and is defined as a JSON number without a fraction or exponent part.
null is not supported as a type (see nullable for an alternative solution).
Models are defined using the Schema Object, which is an extended subset of JSON Schema Specification Wright Draft 00.

Primitives have an optional modifier property: format.
OAS uses several known formats to define in fine detail the data type being used.
However, to support documentation needs, the format property is an open string-valued property, and can have any value.
Formats such as "email", "uuid", and so on, MAY be used even though undefined by this specification.
Types that are not accompanied by a format property follow the type definition in the JSON Schema. Tools that do not recognize a specific format MAY default back to the type alone, as if the format is not specified.

The formats defined by the OAS are:

Common Name	`type`	`format`	Comments
integer	`integer`	`int32`	signed 32 bits
long	`integer`	`int64`	signed 64 bits
float	`number`	`float`
double	`number`	`double`
string	`string`
byte	`string`	`byte`	base64 encoded characters
binary	`string`	`binary`	any sequence of octets
boolean	`boolean`
date	`string`	`date`	As defined by `full-date` - RFC3339
dateTime	`string`	`date-time`	As defined by `date-time` - RFC3339
password	`string`	`password`	A hint to UIs to obscure input.

## DataTypeEnum wirklich mit beginnenden Großbuchstaben? ```yaml ColumnConfig: type: "object" required: - "Guid" properties: Guid: type: "string" Columns: type: "array" items: type: "object" required: - "Designation" - "DataType" - "FieldName" properties: Designation: type: "string" DataType: type: "string" enum: - "String" - "Integer" - "Decimal" - "Boolean" - "Date" - "DateTime" FieldName: type: "string" ``` ## Vielleicht besser ```yaml DataType: type: "string" enum: - "string" - "number" - "boolean" - "date" - "dateTime" ``` ### Data Types [Spec](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.0.0.md#data-types) Primitive data types in the OAS are based on the types supported by the [JSON Schema Specification Wright Draft 00](https://tools.ietf.org/html/draft-wright-json-schema-00#section-4.2). Note that `integer` as a type is also supported and is defined as a JSON number without a fraction or exponent part. `null` is not supported as a type (see [`nullable`](#schemaNullable) for an alternative solution). Models are defined using the [Schema Object](#schema-object), which is an extended subset of JSON Schema Specification Wright Draft 00. <a name="dataTypeFormat"></a>Primitives have an optional modifier property: `format`. OAS uses several known formats to define in fine detail the data type being used. However, to support documentation needs, the `format` property is an open `string`-valued property, and can have any value. Formats such as `"email"`, `"uuid"`, and so on, MAY be used even though undefined by this specification. Types that are not accompanied by a `format` property follow the type definition in the JSON Schema. Tools that do not recognize a specific `format` MAY default back to the `type` alone, as if the `format` is not specified. The formats defined by the OAS are: Common Name | [`type`](#data-types) | [`format`](#dataTypeFormat) | Comments ----------- | ------ | -------- | -------- integer | `integer` | `int32` | signed 32 bits long | `integer` | `int64` | signed 64 bits float | `number` | `float` | | double | `number` | `double` | | string | `string` | | | byte | `string` | `byte` | base64 encoded characters binary | `string` | `binary` | any sequence of octets boolean | `boolean` | | | date | `string` | `date` | As defined by `full-date` - [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) dateTime | `string` | `date-time` | As defined by `date-time` - [RFC3339](https://datatracker.ietf.org/doc/html/rfc3339#section-5.6) password | `string` | `password` | A hint to UIs to obscure input.

Nico_Kroll commented

2024-07-02 11:59:35 +02:00

Typischerweise stehen die types ja in Kleinbuchstaben da. Die enum-Werte sind 1:1 genau so, wie Sie auch im Progress und ggf. auch in der Datenbank zu finden sind. Dadurch sparen wir uns irgendwelche Casing-Übersetzungsprogramme in den API-Klassen und können die Werte direkt rausgeben/weiterverarbeiten.

Diese Werte aus der Columnconfig hier... klar. Ist kein direktes Datenbankfeld, aber ein Bestandteil des Shemas itself. Ich werde darauf achten, dass das in die CommonNames übersetzt wird.

Persönliche Meinung: Ich finde die CommonNames super verwirrend und schrecklich, dass sich sowas als common durchsetzt. Allein der Punkt "dateTime" entspricht "date-time". WTF?! Keine konsequente Benutzung eines Casingstiles.

Typischerweise stehen die types ja in Kleinbuchstaben da. Die enum-Werte sind 1:1 genau so, wie Sie auch im Progress und ggf. auch in der Datenbank zu finden sind. Dadurch sparen wir uns irgendwelche Casing-Übersetzungsprogramme in den API-Klassen und können die Werte direkt rausgeben/weiterverarbeiten. Diese Werte aus der Columnconfig hier... klar. Ist kein direktes Datenbankfeld, aber ein Bestandteil des Shemas itself. Ich werde darauf achten, dass das in die CommonNames übersetzt wird. Persönliche Meinung: Ich finde die CommonNames super verwirrend und schrecklich, dass sich sowas als common durchsetzt. Allein der Punkt "dateTime" entspricht "date-time". WTF?! Keine konsequente Benutzung eines Casingstiles.

Nico_Kroll closed this issue

2024-07-02 11:59:49 +02:00

Sign in to join this conversation.

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: PRM_Software_AG/api-documentation#2