realm-js: Relationship created in atlas/realm ui causes null field in realm js

Goals

Relationship via atlas, to process in realm js.

Expected Results

opUnit field populated with results from collection in opunit table for that particular id key.

Actual Results

opUnit field is null

Steps to Reproduce

Schema 1:

{ “title”: “Parcel”, “properties”: { “_id”: { “bsonType”: “objectId” }, “_partitionKey”: { “bsonType”: “string” }, “opUnit”: { “bsonType”: “string” }, “tourName”: { “bsonType”: “string” } }, “required”: [ “tourName” ] }

### Schema 2: { “properties”: { “_id”: { “bsonType”: “string” }, “tourName”: { “bsonType”: “string” }, “createdAt”: { “bsonType”: “date” } }, “required”: [ “_id”, “tourName”, “createdAt” ], “title”: “OpUnit” }

Relationship in atlas on Parcel Schema:

{ “opUnit”: { “ref”: “#/relationship/mongodb-atlas/tours_db/opunit”, “foreign_key”: “_id”, “is_list”: false } }

  1. create relationship in atlas
  2. open Parcel realm

Code Sample

  Realm.open(config).then(projectRealm => {
    const syncParcels = projectRealm.objects('Parcel');
    syncParcels.forEach(element => console.log(element.opUnit));
  });

Output

image

Version of Realm and Tooling

  • Realm JS SDK Version: ?
  • Node or React Native: ?
  • Client OS & Version: ?
  • Which debugger for React Native: ?/None

Opening in realm studio: image

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 19 (7 by maintainers)

Most upvoted comments

Perhaps that needs to be clarified in the docs. In the Partitioning page, there’s the following section:

Each unique partition value, or value of a partition key, maps to a different realm. Documents that share the same partition value belong to the same realm. All documents in a realm share the same read and write permissions.

What this means is that a Realm with partition ‘xyz’ will only contain documents that have partitionKey (tourName in your case) equal to xyz. The idea of the relationships configuration is to map properties to objects, thus saving you the need to manually lookup items. For example, if you have the following model:

Dog: {
    owner: string // <- maps to Owner._id
}

Owner: {
    _id: string
    company: string // <-- maps to Company._id
}

Company: {
    _id: string
}

To lookup the company where a dog’s owner works, you’d need:

let dog = realm.objectForPrimaryKey("Dog", "my-dog-id");
let dogOwner = realm.objectForPrimaryKey("Owner", dog.owner);
let dogOwnerCompany = realm.objectForPrimaryKey("Company", dogOwner.company);

This is obviously going to get more and more annoying, the more nested your graph gets. It’s also less performant. With relationships, this maps to strongly typed object links in Realm, so the same code looks like:

let dogOwnerCompany = realm.objectForPrimaryKey("Dog", "my-dog-id").owner.company;

It’s also immensely beneficial for GraphQL, where you can issue one query and receive all the results in one response, rather than make hundreds of requests.

Ultimately, relationships and partitioning are unrelated to one another - they solve different problems and don’t affect how the other behaves.

Thanks for reporting this, we are going to take a look into it. 👍