-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenAPI schema generation and model inheritance #3293
Comments
Thank you @ricky92 for reporting the bug, I am able to reproduce it using your sandbox. I did a quick check and I agree with your conclusion that our schema caching is not working correctly. Here is the problematic code: The caching problem seems to be fixed when I add const cached = MetadataInspector.getClassMetadata(JSON_SCHEMA_KEY, ctor, {
ownMetadataOnly: true,
}); Observed schema: {
"title": "TodoEx",
"properties": {
"id": { "type": "number" },
"title": { "type": "string" },
"desc": { "type": "string" },
"isComplete": { "type": "boolean" },
"remindAtAddress": { "type": "string" },
"remindAtGeo": { "type": "string" }
},
"required": [ "title" ]
} I am not sure what is causing this second problem. Anyhow, would you like to investigate this issue further and perhaps contribute a pull request to fix it? See Contributing code in LoopBack 4 and Submitting a pull request to LoopBack 4 to get started. |
I ran into a similar symptom which, in my case at least (not sure if it's exactly the same as here), seems to be caused by the caching of What's happening is that the call to var hasOwn = OrdinaryHasOwnMetadata(MetadataKey, O, P);
if (hasOwn)
return OrdinaryGetOwnMetadata(MetadataKey, O, P);
var parent = OrdinaryGetPrototypeOf(O);
if (!IsNull(parent))
return OrdinaryGetMetadata(MetadataKey, parent, P);
return undefined; And so what happens is that I think the fix may then be to have Workaround I used: Put all the properties in an abstract base class that does not have a |
@mgabeler-lee-6rs that workaround solution worked for me. As a side-note for those of whom are going about this workaround for now. Make sure your relations are in your final leaf classes, not the base abstract class. Otherwise loopback will complain about the relation metadata not compiling correctly. Something like... |
Possible causes Possible Solution We need test cases to confirm this problem, and afterwards confirm that we've fixed the issue. |
Based on #3293 (comment), the problem can be reproduced using the sanbox provided in the bug report, see https://github.com/ricky92/loopback-next/tree/model-inheritance |
When using inheritance in model definitions, the behaviour is inconsistent.
Steps to reproduce
Current Behaviour
As noted, the behaviour is inconsistent, and depends upon the order of occurrence of the parent/child models.
getModelSchemaRef
) are not used on the parent model, the schemas are generated correctly.My guess is there is some sort of caching mechanism (which makes a lot of sense) for the generation of OpenAPI schemas. If so, this mechanism is broken when dealing with inheritance.
Expected Behaviour
Correct generation of both child and parent models' schemas, regardless of their occurrences' positions in controllers.
Acceptance Criteria
Link to reproduction sandbox
https://github.com/ricky92/loopback-next/tree/model-inheritance
Additional information
Platform and node version:
darwin x64 8.16.0
The text was updated successfully, but these errors were encountered: