Loopback-next: Epic: ENUM type (ORM, OpenAPI, etc.)

[bajtos]

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 https://github.com/strongloop/loopback/issues/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
  
  
  
  • SQL connectors, see e.g. https://github.com/strongloop-internal/scrum-loopback/issues/603
  
  
  • MongoDB, see e.g. https://github.com/strongloop-internal/scrum-loopback/issues/604
  
  
  • Cloudant
  
  
  • etc.
  
  
• 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 https://github.com/strongloop/loopback-next/issues/1624
• documentation & blog post

[luncht1me]

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]

any update about this feature?

[zzhenryquezz]

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]

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.

[ludohenin]

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]

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

@agnes512 @nabdelgadir Let's document this.

[InvictusMB]

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

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