-
Notifications
You must be signed in to change notification settings - Fork 58
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
Compose schemas #46 #47
Conversation
a6c43f9
to
4e6c552
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good work! Do you think it could be possible for the inherited schema to be already a JSON schema and not our wrapper?
Thank you @mcollina! The problem is that our in-memory data structure is different. Later I deserialize: So if we want to accept a JSON schema I guess I need to parse it. On the other hand, I'm starting to see that having something like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
This is ok as-is, I would move the discussion on |
Normally inheritance with JSON Schema is achieved with
allOf
. However when.additionalProperties(false)
is used the validator won'tunderstand which properties come from the base schema.
S.extend
creates a schema merging the base into the new one so that the validator knows all the properties because it's evaluating only a single schema.For example in a CRUD API
POST /users
could use theuserBaseSchema
rather thanGET /users
orPATCH /users
use theuserSchema
whose contains theid
,createdAt
andupdatedAt
generated server siderelated to #46