defaultsAsNonNull falsely reports non-nullability for subdocuments that have a Schema #358
Description
Hi @nodkz,
I noticed a small bug in the behaviour of { defaultsAsNonNull: true } when a Schema embeds another Schema.
Here is a simple repro:
const schema = new Schema({
subDocument: new Schema({
})
});
const myModel = model('model', schema);
const tc = composeMongoose(myModel, { defaultsAsNonNull: true });
console.log(tc.getFieldType('subDocument')); // "modelSubDocument!"
console.log(new myModel().toJSON()); // "{ _id: 60f9cdff3d826d1e92a34c14 }"As you can see, the subDocument field is typed as non-nullable modelSubDocument!, but as you can see, once a document instance is created, the property is not defined.
(In this case, Compose detects a default value because of the _id property that Schema is automatically adding, and _id has a default value getter.)
Investigating a little bit more shows that a sub-Schema breaks the "recursive default value assignation" behavior that can be observed with classic subdocuments definitions ({} instead of new Schema({})).
Anything that is under a Schema will not be automatically set according to default values unless the user manually creates that host object.
If you want to test it with just mongoose alone first:
In this case graphql-compose-mongoose gets nullability right:
const schema = new Schema({
subDocument: {
field: { type: String, default: 'Hey' }
}
});
const myModel = model('model', schema);
console.log(new myModel().subDocument); // { field: 'Hey' }In this case graphql-compose-mongoose gets nullability wrong:
const schema = new Schema({
subDocument: new Schema({
field: { type: String, default: 'Hey' }
})
});
const myModel = model('model', schema);
console.log(new myModel().subDocument); // undefined