feature: discriminator

Sorting

• I’m submitting a …

  • bug report
  • feature request
  • support request

• I confirm that I

  • used the search to make sure that a similar issue hasn’t already been submit

Description

I’m using mongoose discriminators for my models, so I have 1 principal model and 3 children. In my controllers, I have a PATCH method to update my models, in this PATCH method all properties are optionals and I can use this method to update any of my children models.

BUT, tsoa need to validate the right schema depending on which model I’m updating. It will be nice if we can have a solution to declare a pre-validation function to tell tsoa which schema to validate against.

Currently, I’m updating the handlebars template to call my custom method (see below) in the patch route instead of validating schema:

  public async validate (validate: (args: any, request: any, response: any) => any[], args: Args, req: express.Request, res: express.Response): Promise<any[]> {
    const dt = await req.models.Datasource.findOne({ _id: new ObjectId(req.params.id) }, 'mode').exec()
    if (!dt) {
      throw new httpErrors.DatasourceNotFound({ id: req.params.id })
    }
    switch (dt.mode) {
      case DatasourceMode.WORKER:
        args.body.ref = 'PatchWorkerDt'
        break
      case DatasourceMode.INGESTER:
        args.body.ref = 'PatchIngesterDt'
        break
      case DatasourceMode.PROXY:
        args.body.ref = 'PatchProxyDt'
        break
    }
    return validate(args, req, res)
  }

Possible Solution

Maybe a decorator to define a custom pre-validation function where we will need to return the type name we need to validate against?

[sureyeaah]

I really need this to be fixed as well. I like the proposal by @devnev, is there any consensus on this?

[devnev]

Looking at the OAS again, I notice the line regarding discriminators:

When using the discriminator, inline schemas will not be considered.

However, the spec is also explicit that the discriminator serves as a hint for serialisation and validation but isn’t necessary for the proper use of oneOf when only one subschema is valid.

Based on that, TSOA could do two separate steps:

1. Check if there’s a field that behaves like a discriminator, in which case use a oneOf instead of an anyOf
2. If additionally that field has a string type and all the subschemas are references, also output a discriminator with a mapping