Type of populated property

[lalchan]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

Following the tutorial in the official NestJs documentation for MongoDB
A populated property can be either a ObjectId or document so handling the populating property can be a little messy.

Also insertions and update with ObjectId seems to not be possible

Although this can be resolved by using union type between ObjectId and the entity, the Entity doesn't have _id in them, which although seems minor enough, _id of the populated document is cannot be fetched without bypassing the typescript type checking.

Describe the solution you'd like

Giving the populated Property it's own type seems to be a good starting point.

The following is how i would imagine it to be:

export type PopulatedEntity<T> = Types.ObjectId | (T & { _id: Types.ObjectId; });

This can be implemented in the @Schema entity as:
@Prop({ type: mongoose.Schema.Types.ObjectId, ref: 'Owner' }) owner: PopulatedEntity<Owner>;

Teachability, documentation, adoption, migration strategy

No response

What is the motivation / use case for changing the behavior?

Following are the use cases where the default implementation cause an issue:

• manipulation(create/update) the populating property of the entity using only the ObjectId of the populated entity.
• fetching the populated property(ObjectId) when it is not populated.
• fetching the _id of the populated property when it is populated.

[ailequal]

I am trying to setup my schema files correctly according to the official Mongoose documentation, but I am stuck as well. I'll go with a union type combined with a manual check child == null || child instanceof ObjectId to safely handle the structures, since the generic given by populate() is ignored by @nestjs/mongoose.

@Schema()
export class Parent() {
  @Prop({
    required: true,
    type: SchemaTypes.ObjectId,
    ref: 'Child',
  })
  child: Types.ObjectId | ChildDocument;
}

I don't know if I am missing something, but for now this seems a good enough approach for my use case.