loopbackio / loopbackio/loopback-next

Robust handling of ObjectID type for MongoDB

Offen
#3,720 2 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Dieses Issue hat noch niemand übernommen.

epic major Repository
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 ObjectID type for primary keys.
  • ObjectID is represented as a string when 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

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 also findById and replaceById), 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

Beitragsleitfaden

Beitragsleitfaden öffnen

Erste Schritte

  1. Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
  3. Forke das Repository und arbeite in einem Branch.
  4. Ö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

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.