Better documentation about adding a new prop with a default value to a nested object/subdocument

[todorpopov93]

Describe what you need | want

Currently, when someone wants to add a new prop with a default value to a subdocument he needs to keep in mind that the subdocument's parent has to explicitly mention the "type" of the subdocument within the @prop decorator, otherwise when querying existing documents from a collation, the default value within the subdocument is ignored and not returned (for those existing documents that are missing the prop at all in the database).

Example

Consider having the following documents and the respective relationship between them:

class Child {
     @prop()
     name: string;
}

class Parent {
    @prop()
    child: Child
}

The problem

And consider that we have already persisted a few documents in the mongodb database and then we decide to add a new property to the Child schema - "age", with a default value of "18", without having to migrate the existing records in the database, but when requesting them, to acquire the age field with it's default value.

class Child {
     @prop()
     name: string;

     @prop({ default: 18 })
     age: number;
}

class Parent {
    @prop()
    child: Child
}

The next time we query the existing records from the database, we'd expect to have the age returned with a default value for every child, but the problem is that the new "age" field that we've added is being totally ignored, despite having a default value.

Do you have already an idea for the implementation?

The simple way of fixing this behaviour, and having the query return the default value is by stating the "type" of the child object, within the Parent, like so:

class Child {
     @prop()
     name: string;

     @prop({ default: 18 })
     age: number;
}

class Parent {
    @prop({ type: Child })
    child: Child
}

Apparently, without the "type" option in the @prop decorator, all the new props added to the nested document are not being returned, despite having a default value set to them on schema level.

Also this behaviour / pitfall was not mentioned anywhere in the Typegoose's documentation, and I'd expect it to be mentioned in the "default" section of the @prop decorator's page -> https://typegoose.github.io/typegoose/docs/api/decorators/prop/#default

[hasezoey]

Apparently, without the "type" option in the @prop decorator, all the new props added to the nested document are not being returned, despite having a default value set to them on schema level.

explicitly setting type for this case should not matter, as long as not running issues like Use Without "emitDecoratorMetadata" or that arrays always require type option.

aside from this, from what i know on how mongoose works, defaults are only added if the document is new (ie not fetched from the database, even if its a new property).
also, defaults will only get set for a sub-document when the parent's path sets default: {} (ie default non-undefined object), otherwise the paths will be "unset" (basically undefined).

---

though yes, what i said above should be added to the documentation