Repository navigation
Name clashes between auto-generated models and explicitly defined models #323
Description
Describe the bug
We have a model Entity with a property schema:
Entity:
type: object
additionalProperties: false
properties:
schema:
allOf:
- "$ref": "#/components/schemas/SchemaSummary"
nullable: true
and we also have a model EntitySchema.
The auto-generated client has a model EntitySchema, which refers to the property on Entity, but it silently ignores the explicitly defined EntitySchema model.
To Reproduce
Generate the client with Entity and EntitySchema as above.
Expected behavior
There should be two separate models, one for the Entity.schema property, one for EntitySchema.
OpenAPI Spec File
See above
Desktop (please complete the following information):
- OS: 10.15.4
- Python Version: 3.8.5
- openapi-python-client version v0.7.3
Activity
forest-benchling commentedon Feb 1, 2021
cc @bowenwr @dtkav, I see that we have worked around this for now by naming it
TagSchemaandBatchEntitySchema, but not ideal in the long rundbanty commentedon Feb 1, 2021
I believe you can use the
titleattribute to effectively choose a class name instead of relying on auto-generation. Not sure how that works with properties, but the reason I insist on keeping that feature despite some arguments to the contrary is precisely to give a tool around naming collisions.That being said, we certainly shouldn't be skipping it silently, there should be some sort of an error that we generated the name twice. Also, we probably want the ability to override class names in config to be able to point at specific components rather than based on generated class name, so you can solve the collision without changing the OpenAPI document.
This is somewhat related to #300 which is trying to deal with the issue of component resolution vs class name deduplication. Fixing that wouldn't fix this, but if you are looking to write a solution involving the
Schemas.modelsin the parser you probably should read that PR first.dbanty commentedon Apr 4, 2021
I think that this is as resolved as it can be with #336 being done, so I'm going to close it.