Why ObjectId type is such extremly complex? about mongoose HOT 6 CLOSED

What specifically is complex about the ObjectId type? Is the source code too long? Too many helpers? Too many possible argument types to the ObjectId constructor?

from mongoose.

@vkarpov15 No, the complexity comes from the SchemaType of mongoose.

It is the reason why making validation code be such long (read my links of top please).

Also. here is the list of every object types referenced from the ObjectId type of the mongoose. In my opinion, it seems not intended spec, but of mistake. Maybe many of them can be disabled just by adding @internal tag.

• 'mongoose'.Schema.Types.ObjectId
• Record<string, any>
• 'mongoose'.SchemaTypeOptions<any, any>
• Function
• RegExp
• 'mongoose'.ValidateOpts<any>
• 'mongoose'.ValidatorMessageFn
• 'mongoose'.ValidateFn<any>
• 'mongoose'.LegacyAsyncValidateFn<any>
• 'mongoose'.AsyncValidateFn<any>
• Model<any, __type, __type, __type, any, any>
• "mongoose"
• 'mongoose'.Collection<Document>
• 'mongoose'.Connection
• __type
• Db
• Readonly<__type>
• "events".global.NodeJS.EventEmitter
• __type.o1
• 'mongoose'.Schema<any, Model<any, any, any, any, any, any>, __type, __type, __type, __type, 'mongoose'.DefaultSchemaOptions, __type, Document<unknown, {}, FlatRecord<{ [x: string]: any; }>> & FlatRecord<{ [x: string]: any; }> & Required<{ _id: unknown; }>>
• __type.o2
• __type.o3
• AddThisParameter<{}, Document<unknown, {}, FlatRecord<{ [x: string]: any; }>> & FlatRecord<{ [x: string]: any; }> & Required<{ _id: unknown; }>> & AnyObject
• __type.o4
• 'mongoose'.SchemaType
• 'mongoose'.SchemaType<any, any>
• 'mongoose'.AnyObject
• 'mongoose'.Validator
• 'mongoose'.Schema.Types.Mixed
• 'mongoose'.Schema.Types.Mixed.o1
• 'mongoose'.Schema<any, any, any, __type, __type, __type, 'mongoose'.DefaultSchemaOptions, __type, Document<unknown, {}, FlatRecord<{ [x: string]: any; }>> & FlatRecord<{ [x: string]: any; }> & Required<{ _id: unknown; }>>
• __type.o5
• __type.o6
• AddThisParameter<any, Document<unknown, {}, FlatRecord<{ [x: string]: any; }>> & FlatRecord<{ [x: string]: any; }> & Required<{ _id: unknown; }>> & AnyObject
• __type.o7
• StringConstructor
• 'mongoose'.Schema.Types.String
• 'mongoose'.Schema.Types.String.o1
• NumberConstructor
• 'mongoose'.Schema.Types.Number
• 'mongoose'.Schema.Types.Number.o1
• BooleanConstructor
• 'mongoose'.Schema.Types.Boolean
• 'mongoose'.Schema.Types.Boolean.o1
• NativeDate
• NativeDate.o1
• 'mongoose'.Schema.Types.Date
• 'mongoose'.Schema.Types.Date.o1
• 'mongoose'.Schema<any, any, any, __type, __type, __type, 'mongoose'.DefaultSchemaOptions, __type, Document<unknown, {}, FlatRecord<{ [x: string]: any; }>> & FlatRecord<{ [x: string]: any; }> & Required<{ _id: unknown; }>>.o1
• __type.o8
• __type.o9
• __type.o10
• __type.o11
• {} & { [name: string]: (this: any, ...args: any[]) => unknown; }
• 'mongoose'.MixedSchemaTypeOptions<any>
• 'mongoose'.ValidateOpts<'mongoose'.Schema.Types.Mixed>
• 'mongoose'.ValidateFn<'mongoose'.Schema.Types.Mixed>
• 'mongoose'.LegacyAsyncValidateFn<'mongoose'.Schema.Types.Mixed>
• 'mongoose'.AsyncValidateFn<'mongoose'.Schema.Types.Mixed>
• 'mongoose'.IndexOptions
• Record<string, number>
• Document
• ReadConcern
• __type.o12
• CollationOptions
• ClientSession
• MongoOptions
• HostAddress
• MongoCredentials
• AuthMechanismProperties
• ReadPreference
• TagSet
• HedgeOptions
• ServerApi
• WriteConcern
• ClientMetadata
• __type.o13
• __type.o14
• __type.o15
• __type.o16
• Int32
• AutoEncryptionOptions
• MongoClient
• __type.o17
• Record<string, never>
• __type.o18
• __type.o19
• "buffer".global.Buffer
• __type.o20
• __type.o21
• __type.o22
• __type.o23
• __type.o24
• __type.o25
• __type.o26
• __type.o27
• ProxyOptions
• CSFLEKMSTlsOptions
• ClientEncryptionTlsOptions
• DriverInfo
• PkFactory
• "tls".KeyObject
• "tls".PxfObject
• "tls".SecureContext
• __type.o28
• ClusterTime
• Timestamp
• __type.o29
• __type.o30
• Binary
• Long
• TransactionOptions
• Transaction
• __type.o31
• __type.o32
• 'mongoose'.SchemaTypeOptions<any, any>.o1
• __type.o33
• {} & { [name: string]: (this: any, ...args: any[]) => unknown; }.o1
• 'mongoose'.SchemaTypeOptions<any, any>.o2
• __type.o34
• {} & { [name: string]: (this: Model<any, any, any, any, any, any>, ...args: any[]) => unknown; }

from mongoose.

I don't know how you're generating this code, but one potential issue is that you say typia doesn't require schema definitions, but you're validating that the given value is an instance of the ObjectId SchemaType rather than an ObjectId. If I'm understanding things correctly, typia.createIs<ObjectId>(); should check if the given value is an instance of mongoose.Types.ObjectId, not mongoose.Schema.Types.ObjectId.

If you're looking for a runtime check that a value is something Mongoose can convert to an ObjectId, then you should just use mongoose.isValidObjectId().

from mongoose.

typia just analyzes TypeScript types through compiler API, and writes dedicated validation code suitable for the target type. That's all.

Therefore, it is not possible to adding special validation logic to calling the mongoose.isValidObjectId() function, only for the mongoose.ObjectId type. Also, it is possible to performing the instanceof statement. However, individual member properties' validation is still required, because one of them can be wrong.

In such reason, to solve the issue of my library typia, mongoose.ObjectId type (of mongoose/types/schematypes.d.ts) must be changed to erasing vulnerable properties. If not, no way for me. In that case, I just have to guide my users not to validate the mongoose model instances through typia's functions, introducing such special stories.

@Controller("bbs/articles")
export class BbsArticlesController {
  @TypedRoute.Post()
  public async store(
    // the validation must be done in here, and typia does it
    @TypedBody() input: IBbsArticle.IStore
  ): Promise<IBbsArticle> {
      // transformation to the mongoose model class instance must be done after the raw data validation
  }
}

By the way, from a general perspective on the backend development, DTO types should be separated with ODM types. When the backend server gets some data from a remote client through the network communication like Rest API, the instance is not a specific class instance, but a primitive instance. Validation must be done at that step, the raw data level. The starting point of all problems is right here. Why do they want to validate the ODM type?

Anyway, it would be nice if mongoose.ObjectId has a more reasonable type, but this is entirely up to you as the author of mongoose. Whatever you decide, I think the fundamental problem comes from some special typia users violating the principle, "separating DTO and ODM types". I'm just reporting this issue due to too many people are taking same mistakes repeatedly for a long time. Thanks for reading long issue, comments, and special stories.

In my personal opinion, I think Mongoose's model types need some improvements, regardless of this issue.

from mongoose.

Ok, so why is typia analyzing mongoose.ObjectId rather than mongoose.Types.ObjectId? mongoose.ObjectId is the ObjectId SchemaType class, not the ObjectId class. And users typically want to validate that a value is an ObjectId, not an ObjectId SchemaType.

from mongoose.

Understood, the mongoose.Types.ObjectId has only one property _id.

Thanks for replying, and I'll just guide to like thatthat, if someone raises up same issue.

from mongoose.