Open bajtos opened 5 years ago
Loopback 3 has AccessToken _id of type string. I have an app using db generated by lb3 and reuse in an lb4 app. How can i use _id as type string?
there is something confused by setting mongodb: {dataType: 'ObjectID'},
in my loopback4 application.
When the MongoDB connector returns data from database, it converts ObjectID values to strings.
as above say, if I get a model User,and I call the this.userRepository.create(user),it will return a User object instance,UserInstance.
according to my understand of citing criteria,I expect
typeof(UserInstance.id) == string
typeof(UserInstance) == object
this make me confused about the criteria cited above.
please give me some instruction.
@bajtos
MongoDB is tricky - see https://github.com/strongloop/loopback-next/issues/1875
ObjectID
type for primary keys.ObjectID
is represented as astring
when converted to JSON'some-id' !== ObjectID('some-id')
.As a result, both PK and FK properties must use
ObjectID
as the type, and coercion must be applied where necessary.Ideally, I'd like LB4 to define MongoDB PK and FKs as follows:
{type: 'string', mongodb: {dataType: 'ObjectID'}}
Even better,
dataType: 'ObjectID'
should be automatically applied by the connector for PK and FKs referencing ObjectID PKs.For example:
For v1, I suppose we can ask developers to provide dataType manually.
With this setup in place,
id
andcategoryId
properties should be always returned as strings from DAO and connector methods.Related discussions
dataType: 'mongodb'
: https://github.com/strongloop/loopback-connector-mongodb/pull/517 and https://github.com/strongloop/loopback-connector-mongodb/pull/525Acceptance criteria
For every property defined as
{type: 'string', mongodb: {dataType: 'ObjectID'}}
, including properties defined in nested/embedded models:filter.where
, but alsofindById
andreplaceById
), it converts string values to ObjectID. The conversion is applied to non-trivial conditions too, e.g.{where: {id: { inq: ['my-objectid-1', 'my-objectid-2'] }}}
Documentation page for MongoDB users explaining extra configuration needed
Blog post announcing the improvements
Tasks