# Why \`subtypeNameToSchemaName\` in Schema derivation always recalculates Snames

**URL:** <https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409>\
**Category:** tapir\
**Created:** [June 12, 2024, 10:04am UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409 "2024-06-12T10:04:31Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [June 12, 2024, 10:04am UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/1 "2024-06-12T10:04:31Z")

</div>

I was wondering why `subtypeNameToSchemaName` in `SchemaMagnoliaDerivation` always recalculates names based on TypeName, instead eg. attempting to get those names from known Schema.name and if it doesn’t exist then fallback to TypeName.

IN MY HEAD that would/could resolve issue of semiauto derivation loosing type info of params.

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [June 12, 2024, 11:04am UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/2 "2024-06-12T11:04:59Z")

</div>

That’s a good question - I don’t know off the top of my head. Maybe you can try changing and seeing what breaks? There’s a lot of tests in `openApiDocs` which should help to quickly verify the behavior.

---

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [June 12, 2024, 1:27pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/3 "2024-06-12T13:27:47Z")

</div>

I did change it, tests passed, but it seems there is no value in it, that change or not semiauto derivation for anything with generic params is completly broken.

Is that semiauto issue magnolia bug? or some scala type system corner case?

Wonder if we could have typeclass for each generic argument to hack around it 😄

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [June 12, 2024, 1:40pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/4 "2024-06-12T13:40:31Z")

</div>

Which semiauto issue? I would rather bet on a problem in tapir, than in magnolia.

---

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [June 12, 2024, 1:42pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/5 "2024-06-12T13:42:32Z")

</div>

eg:  
scala 2.13

```auto
package com.test

import io.circe.generic.auto._
import sttp.apispec.openapi.circe.yaml.RichOpenAPI
import sttp.tapir._
import sttp.tapir.docs.openapi.OpenAPIDocsInterpreter
import sttp.tapir.json.circe.jsonBody

object Test extends App {

  lazy implicit val someValueStringSchema: Schema[SomeValueString] = Schema.derived
  lazy implicit val someValueIntSchema: Schema[SomeValueInt] = Schema.derived
  lazy implicit val hasStringTreeSchema: Schema[HasStringTree] = Schema.derived
  lazy implicit val hasIntTreeSchema: Schema[HasIntTree] = Schema.derived

  @inline
  implicit def adtTreeSchema[A: Schema]: Schema[AdtTree[A]] = Schema.derived[AdtTree[A]]

  val endpoint1 = endpoint
    .put
    .name("test1")
    .in("test" / "1")
    .in(jsonBody[AdtTree[SomeValueString]])

  val endpoint2 = endpoint
    .put
    .name("test2")
    .in("test" / "2")
    .in(jsonBody[AdtTree[SomeValueInt]])

  val endpoints = List(endpoint1, endpoint2)

  val yamlString: String = OpenAPIDocsInterpreter()
    .toOpenAPI(endpoints, "test", "v1")
    .toYaml

  println(yamlString)

}

sealed trait AdtTree[A]
object AdtTree {
  final case class AdtLeaf[A](a: A) extends AdtTree[A]
  final case class AdtNode[A](trees: List[AdtTree[A]]) extends AdtTree[A]
}

final case class SomeValueString(value: String)
final case class SomeValueInt(value: Int)
final case class HasStringTree(value: String, tree: AdtTree[SomeValueString])
final case class HasIntTree(value: String, tree: AdtTree[SomeValueInt])

```

generates:

```auto
openapi: 3.1.0
info:
  title: test
  version: v1
paths:
  /test/1:
    put:
      operationId: test1
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/AdtTree_A'
        required: true
      responses:
        '200':
          description: ''
        '400':
          description: 'Invalid value for: body'
          content:
            text/plain:
              schema:
                type: string
  /test/2:
    put:
      operationId: test2
      requestBody:
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/AdtTree_A'
        required: true
      responses:
        '200':
          description: ''
        '400':
          description: 'Invalid value for: body'
          content:
            text/plain:
              schema:
                type: string
components:
  schemas:
    AdtLeaf_A:
      title: AdtLeaf_A
      type: object
      required:
      - a
      properties:
        a:
          $ref: '#/components/schemas/SomeValueString'
    AdtNode_A:
      title: AdtNode_A
      type: object
      properties:
        trees:
          type: array
          items:
            $ref: '#/components/schemas/AdtTree_A'
    AdtTree_A:
      title: AdtTree_A
      oneOf:
      - $ref: '#/components/schemas/AdtLeaf_A'
      - $ref: '#/components/schemas/AdtNode_A'
    SomeValueInt:
      title: SomeValueInt
      type: object
      required:
      - value
      properties:
        value:
          type: integer
          format: int32
    SomeValueString:
      title: SomeValueString
      type: object
      required:
      - value
      properties:
        value:
          type: string

```

---

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [June 12, 2024, 1:43pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/6 "2024-06-12T13:43:56Z")

</div>

where test 1 endpoint should take string tree, and test 2 int tree.

and generated docs result in it taking string on both.

auto - `SchemaDerivation` works as expected

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [June 12, 2024, 1:55pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/7 "2024-06-12T13:55:17Z")

</div>

Oh … that’s “interesting”. I’d have to take a look. As a work-around, you should be able to customise the semi-auto-derived schemas with correct names, as described [here](https://tapir.softwaremill.com/en/latest/endpoint/schemas.html#customising-derived-schemas).

```auto
lazy implicit val hasIntTreeSchema: Schema[HasIntTree] = Schema.derived

```

---

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [June 12, 2024, 1:58pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/8 "2024-06-12T13:58:11Z")

</div>

yea I know that, just it is quite error prone and I hoped for some better solution

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [June 12, 2024, 2:13pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/9 "2024-06-12T14:13:03Z")

</div>

Ok great, yeah I agree, but that needs some dev-time, we’ll get there eventually 🙂

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [June 17, 2024, 3:48pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/10 "2024-06-17T15:48:11Z")

</div>

Is the above reported as an issue in tapir?

---

<div class="post-metadata">

**Author:** ![lgmyrek](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/lgmyrek/32/272_2.png) [@lgmyrek](https://softwaremill.community/u/lgmyrek)\
**Post date:** [July 10, 2024, 12:22pm UTC](https://softwaremill.community/t/why-subtypenametoschemaname-in-schema-derivation-always-recalculates-snames/409/11 "2024-07-10T12:22:22Z")

</div>

no, sorry I’ve missed that response