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

Epic: ENUM type (ORM, OpenAPI, etc.) #3033

Closed
bajtos opened this issue Jun 3, 2019 · 11 comments
Closed

Epic: ENUM type (ORM, OpenAPI, etc.) #3033

bajtos opened this issue Jun 3, 2019 · 11 comments
Labels
epic feature Repository Issues related to @loopback/repository package REST Issues related to @loopback/rest package and REST transport in general stale Validation

Comments

@bajtos
Copy link
Member

bajtos commented Jun 3, 2019

Implement a new property type - enum (enumeration).

Example model definition:

@model()
class Person extends Entity {
  @property({
    type: 'string',
    enum: ['male', 'female', 'other'],
  })
  gender: string;
}

This issue is a replacement for strongloop/loopback#1321 that's tracking ENUM feature request in LoopBack 3.x

Areas to cover:

  • support both string and number as a backing datatype
  • loopback-datasource-juggler should validate property values of enum type inside DAO methods like create and updateAttributes
  • automigration: connectors should map enum type to appropriate database counterpart during database schema migration
  • autodiscovery: connectors should add enum constraint to the discovered definitions where applicable
  • JSON Schema and OpenAPI: code converting model definitions to JSON Schema and OpenAPI Schema should recognize enum and include the constraint in the schema produced
  • @loopback/rest should validate ENUM constraints for input parameters, see Complex OpenAPI Validations with @property #1624
  • documentation & blog post
@bajtos bajtos added feature epic Validation REST Issues related to @loopback/rest package and REST transport in general Repository Issues related to @loopback/repository package labels Jun 3, 2019
@luncht1me
Copy link

I'm currently looking for a way to validate properties on my model of a string type to only be one of an allowed value. This would be a great help as I'm having trouble finding the "loopback way" to do it. My current solution was to iterate over an enum with a custom interceptor... But I don't really like that approach.

@11arn11
Copy link

11arn11 commented Jan 19, 2020

any update about this feature?

@zzhenryquezz
Copy link

Works if you put the enum in jsonSchema object

@model()
class Person extends Entity {
  @property({
    type: 'string',
    jsonSchema: {
        enum: ['male', 'female', 'other'],
    }    
  })
  gender: string;
}

@dougal83
Copy link
Contributor

dougal83 commented Apr 24, 2020

Works if you put the enum in jsonSchema object

@zzhenryquezz Take care in using this though as it may not be validating input. See comment.

Also please use the voting system and refrain from creating comments that add no value to conversation such as +1. FYI - This just creates noise in notification feeds.

@loopbackio loopbackio deleted a comment from zzhenryquezz Apr 24, 2020
@ludohenin
Copy link
Contributor

Take care in using this though as it may not be validating input. See comment.

@dougal83 I check on my side with the enum defined at property level (decorator) and this works perfectly (validation at controller level at least and spec generated). Enum as to be specified in a specific way tho

enum QueryLanguage {
  JSON = 'json',
  SQL = 'sql',
}

// ...

@property({
  type: 'string',
  required: true,
  jsonSchema: {
    enum: Object.values(QueryLanguage),
  },
})
queryLanguage: QueryLanguage;

@zzhenryquezz
Copy link

@dougal83 I check on my side with the enum defined at property level (decorator) and this works perfectly (validation at controller level at least and spec generated). Enum as to be specified in a specific way tho

enum QueryLanguage {
  JSON = 'json',
  SQL = 'sql',
}

// ...

@property({
  type: 'string',
  required: true,
  jsonSchema: {
    enum: Object.values(QueryLanguage),
  },
})
queryLanguage: QueryLanguage;

Yep, this is how I use here too. If you pass a normal enum will not work, probably because the jsonSchema expects an array of string or number but the enum of Typescript is converted to an object.

But this way works well for me.

@raymondfeng
Copy link
Contributor

raymondfeng commented Apr 24, 2020

@agnes512 @nabdelgadir Let's document this.

@InvictusMB
Copy link
Contributor

@zzhenryquezz @raymondfeng

Works if you put the enum in jsonSchema object

@model()
class Person extends Entity {
  @property({
    type: 'string',
    jsonSchema: {
        enum: ['male', 'female', 'other'],
    }    
  })
  gender: string;
}

I have an issue with this approach. lb4 inlines this jsonSchema fragment into both Person and PersonWithRelations schemas. Which in turn causes the openapi-generator to create 2 separate enums in typescript code therefore making Person and PersonWithRelations types on the client side not compatible.
Is there a way to extract this piece into a reusable ref or tell lb4 to make PersonWithRelations extend Person schema?

@asarver
Copy link

asarver commented Aug 7, 2020

how would we handle an array of enums using the above example/workaround? figured that out 🙂

@stale
Copy link

stale bot commented Jul 14, 2021

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

@stale stale bot added the stale label Jul 14, 2021
@stale
Copy link

stale bot commented Aug 13, 2021

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.

@stale stale bot closed this as completed Aug 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
epic feature Repository Issues related to @loopback/repository package REST Issues related to @loopback/rest package and REST transport in general stale Validation
Projects
None yet
Development

No branches or pull requests

9 participants