We have encountered an issue with the OpenAPI specifications related to the definition of the FilteringTerm objects.
Problem Details:
The issue arises because the FilteringTerm object is defined in two different locations within the OpenAPI documents, which is causing name conflicts during code generation. Each definition is intended to represent a different object, but they share the same name, as shown below:
Due to this duplicate naming, when generating code from the OpenAPI documents (e.g., in Python), the models are generated with conflicting names such as filtering_term.py and filtering_term1.py. This naming conflict can lead to confusion and errors in the generated code, making it difficult to maintain and use.
Possible Solution:
A possible solution to this issue would be to rename one or both of the FilteringTerm definitions to ensure unique and descriptive names that reflect their distinct purposes.
For example, the FilteringTerm definition in beaconFilteringTermsResults.yaml could be renamed to ResponseFilteringTerm while the FilteringTerm definition in filteringTerms.yaml could keep it's short name due to it's frequent use in user requests.
Note:
I understand the current move away from "OpenAPI first" (#40), but I believe this is important as even generated OpenAPI docs may contains this issue.
We have encountered an issue with the OpenAPI specifications related to the definition of the
FilteringTerm
objects.Problem Details:
The issue arises because the
FilteringTerm
object is defined in two different locations within the OpenAPI documents, which is causing name conflicts during code generation. Each definition is intended to represent a different object, but they share the same name, as shown below:framework/src/requests/filteringTerms.yaml
framework/src/responses/sections/beaconFilteringTermsResults.yaml
Due to this duplicate naming, when generating code from the OpenAPI documents (e.g., in Python), the models are generated with conflicting names such as
filtering_term.py
andfiltering_term1.py
. This naming conflict can lead to confusion and errors in the generated code, making it difficult to maintain and use.Possible Solution:
A possible solution to this issue would be to rename one or both of the
FilteringTerm
definitions to ensure unique and descriptive names that reflect their distinct purposes.For example, the
FilteringTerm
definition inbeaconFilteringTermsResults.yaml
could be renamed toResponseFilteringTerm
while theFilteringTerm
definition infilteringTerms.yaml
could keep it's short name due to it's frequent use in user requests.Note:
I understand the current move away from "OpenAPI first" (#40), but I believe this is important as even generated OpenAPI docs may contains this issue.