loopbackio / loopbackio/loopback-next
Robust handling of ObjectID type for MongoDB
Dieses Issue hat noch niemand übernommen.
- Vorherrschende Sprache
- TypeScript
- Sterne
- 5.1k
- Forks
- 1.1k
- Ø Merge
- 2 T. 21 Std.
- Gemergte PRs (30 T.)
- 27
Beschreibung
MongoDB is tricky - see https://github.com/strongloop/loopback-next/issues/1875
- It uses a custom
ObjectIDtype for primary keys. ObjectIDis represented as astringwhen converted to JSON- In queries, string values must be cast to ObjectID, otherwise they are not considered as the same value:
'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:
@model()
class Product {
@property({
type: 'string',
generated: true,
// ^^ implies dataType: 'ObjectID'
})
id: string;
@property({
type: 'string',
references: {
model: () => Category,
property: 'id',
},
// ^^ implies dataType: 'ObjectID' when Category is attached to MongoDB
})
categoryId: string;
}
For v1, I suppose we can ask developers to provide dataType manually.
@model()
class Product {
@property({
type: 'string',
generated: true,
mongodb: {dataType: 'ObjectID'},
})
id: string;
@property({
type: 'string',
mongodb: {dataType: 'ObjectID'},
})
categoryId: string;
}
With this setup in place, id and categoryId properties should be always returned as strings from DAO and connector methods.
Related discussions
- The issue that started the discussion for LB4: Type ObjectID for model property #1875
- Model inclusion resolvers are tricky when ObjectID gets involved - see https://github.com/strongloop/loopback-next/pulls
- Long-term proposal for fixing ObjectID in LB 3.x: https://github.com/strongloop/loopback/issues/1874
- Short-term fix for LB 3.x that was never finished: https://github.com/strongloop/loopback-datasource-juggler/pull/778
- Recent improvements in loopback-connector-mongodb to honor
dataType: 'mongodb': https://github.com/strongloop/loopback-connector-mongodb/pull/517 and https://github.com/strongloop/loopback-connector-mongodb/pull/525
Acceptance criteria
-
For every property defined as
{type: 'string', mongodb: {dataType: 'ObjectID'}}, including properties defined in nested/embedded models:- When the MongoDB connector returns data from database, it converts ObjectID values to strings.
- When the MongoDB connector writes data to database, it converts string values to ObjectID
- When the MongoDB connector queries database (think of
filter.where, but alsofindByIdandreplaceById), 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
- Model.toObject() should preserve prototypes (e.g. Date and ObjectID values) #3607
- Spike (initial research & PoC implementation): https://github.com/strongloop/loopback-next/issues/3456
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Rechercherichtung
Beginne mit dem Spike in Issue #3456 und den verknüpften Diskussionen zum MongoDB connector; untersuche die Behandlung zurückgegebener Daten, Schreibvorgänge, filter.where, findById und replaceById im Connector sowie die Aufgabe Model.toObject() #3607. Erledigt ist die Aufgabe, wenn ObjectID-Werte in allen aufgeführten Fällen konvertiert werden, einschließlich verschachtelter Modelle und komplexer Bedingungen, und eine MongoDB-Benutzerdokumentation sowie ein Blogbeitrag hinzugefügt wurden.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- mongodb, typescript
- Bereich
- backend, databases
- Issue-Typ
- Feature
- Schwierigkeit
- 5/5
- Geschätzter Aufwand
- Über eine Woche
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 25/100