A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://www.mongodb.com/docs/atlas/app-services/sync/data-model/data-model-map/ below:

Data Model Mapping - Atlas App Services

This page contains information on how the App Services schema used by Atlas Device Sync maps to the SDK object model used by the Atlas Device SDKs.

To learn how to generate these data models, refer to the following pages:

To learn more about how Device Sync uses these two data models, refer to the Sync Data Model Overview.

When you configure Device Sync, you specify the data source where you want to store data. This data source may contain multiple databases, and each database may contain multiple collections.

The App Services schema maps your Realm Database object names to collections in databases in your Device Sync data source. The title field in an App Services schema maps to the object type name in Realm Database. Because the title name determines the mapping between client objects and the appropriate Atlas collection, this name must be unique among all schemas in your synced data source.

The title does not need to match the collection name.

Example

Consider an app with a database named Pets. It may contain multiple collections, such as Canine and Feline. The App Services schema for the Canine collection might resemble the example below, where the title field of the schema is Dog. That would map a Realm Database object called Dog to the Canine collection in the Pets database.

You could not have another schema whose title was Dog in the same cluster. For example, you could not sync an object with a title of Dog to both a Debug and a Test database in the same cluster. If you want to sync the same object to different collections for app development purposes, you must use different data sources - one cluster for development and a different cluster for production.

When you enable Development Mode in your Device Sync configuration, App Services can automatically create collections and schemas for Realm Database objects that you sync. It creates those collections in the database you specify when you enable Development Mode.

With Development Mode enabled, Sync looks for a collection whose App Services schema has a title that matches the name of your Realm Database object type. This collection could be in any database in your linked data source. It doesn't have to be in the database you add when you configure Development Mode.

If there is no corresponding title in any App Services schema in your linked data source, App Services creates a new collection for this object type. This collection is created in the database you specify when you enable Development Mode. The collection name matches the object's type, and the corresponding App Services schema has a title field whose value is the name of the object type. This creates the mapping between your Realm Database object and the new collection.

Example

Consider an Atlas cluster with a database named Pets. It contains a Feline collection with existing data.

In your application code, you define a new Dog object. You enable Development Mode, and specify the Pets database as the database in which to create collections for new object types. When you sync your new Dog object, App Services creates a Dog collection in the Pets database and creates a schema for it. The title of the object in the schema is Dog.

If you later add a new Person object to your application code and then sync it, App Services creates a new collection for this Person object in the Pets database. If you wanted to create a collection for the Person object in a different database, you could Define & Enforce a Schema for the Person object in a different database. Or you could disable and re-enable Development Mode, and select a different database in which to create new collections.

The title field contains the name of the object type represented by the schema. This is equivalent to a class or schema name in an Atlas Device SDK. The type name must be unique among all schemas in your synced cluster but is otherwise arbitrary and does not need to match the collection name.

A conventional approach is to name each object type with a singular noun, like "Dog" or "Person". Schemas generated in development mode or by sampling existing documents use this convention.

Note

To work with Atlas Device Sync, type names cannot exceed 57 UTF-8 characters.

You can configure the following constraints for a given property:

Parameter

Type

Description

Type

String

Every property in a SDK object model has a strongly defined data type. A property's type can be a primitive data type or an object type defined in the same SDK object model. The type also specifies whether the property contains a single value or a list of values.

Realm Database supports the following property types:

For more information on supported data types, refer to Schema Types.

Optional

Boolean

Optional properties may contain a null value or be entirely omitted from an object. By default, all properties are optional unless explicitly marked as required.

Default

Boolean

If a client application creates a new object that does not have a value for a defined property, the object uses the default value instead.

If you open a database in the client with a schema subset that doesn't include a required property, the server will automatically populate the value of the required property with a zero or blank default value.

When you attempt to create an object that is missing a value for a required field, it fails validation and does not persist to the realm.

Indexed

Boolean

A property index significantly increases the speed of certain read operations at the cost of additional overhead for write operations. Indexes are particularly useful for equality comparison, such as querying for an object based on the value of a property. However, indexes consume additional storage.

For SDK-specific details about data types, refer to the following:

Both SDK object models and App Services schemas support array properties.

For SDK-specific details about array properties, refer to the following:

For more information on modeling array properties in an App Services schema, refer to BSON Types - Array. App Services schemas support certain constraints that SDK object models do not, such as specifying the minimum and maximum number of items.

Both SDK object models and App Services schemas support mixed type properties.

A mixed field can contain any supported data type and functionally acts as an object or document without a pre-defined structure.

For more information on modeling mixed properties in an App Services schema, refer to Mixed - Schema Types.

Note Apps created after May 28, 2024

App Services Apps created after May 28, 2024 can store collections (arrays and dictionaries) of mixed data within a mixed data property. You can nest collections within other collections, which lets you store complex data structures such as JSON or MongoDB documents without having to define a strict data model.

To use this feature with Atlas Device SDK, you must use one of the following minimum SDK versions:

This feature is not supported in the Java SDK.

You can contact Support to learn more about enabling this feature in an existing app using a supported SDK.

You can leverage collections (arrays or dictionaries) in mixed properties to store data that does not fit into a pre-defined schema, such as variable JSON data or complex MongoDB documents. Because collections of mixed data can contain other collections of mixed data, you can nest data into complex structures. For an example, refer to the Example Document: Nested Collections of Mixed Data on this page.

You can store collections in mixed data types in an App Services schema or in an SDK object model schema.

For SDK-specific details about mixed data types, refer to the following:

Note New Java SDK Apps Cannot Use RealmAny

New App Services Apps using Java SDK cannot synchronize data models with properties of type RealmAny. To use mixed data types with Device Sync in your app, use the Kotlin SDK.

Embedded objects are embedded as nested data inside of a parent object. An embedded object inherits the lifecycle of its parent object. It cannot exist as an independent database object.

For SDK-specific details about embedded objects, refer to the following:

For more information on modeling to-one relationships in an App Services schema, refer to Embedded Object Relationships.

SDK object models and App Services schemas both support the Set data type. A set is a collection of unique values.

For SDK-specific details about sets, refer to the following:

For more information on modeling sets in an App Services schema, refer to Set.

SDK object models and App Services schemas both support the Dictionary data type. A set is a collection of unique values. A dictionary is a collection of dynamic and unique string keys paired with values of a given type. A dictionary is functionally an object or document without pre-defined field names.

For SDK-specific details about dictionaries, refer to the following:

For more information on modeling dictionaries in an App Services schema, refer to Dictionary.

SDK object models support the following types of relationships:

App Services schemas support to-one and to-many relationships. App Services schemas do not support inverse relationships.

For SDK-specific details about relationships, refer to the following:

For more information on modeling relationships in an App Services schema, refer to Relationships.

Geospatial data describes points and other data on the Earth's surface. App Services does not have built-in geospatial types. Instead, you model geographic data using standard GeoJSON objects. For more information on geospatial data, refer to Schema Types.

For SDK-specific details about geospatial data, refer to:

This example shows how to model a Dog with Device Sync.

This App Services schema creates the Dog data model used by Device Sync.

Dog data model defined in App Services schema

{  "title": "Dog",  "bsonType": "object",  "required": [    "_id",    "name"  ],  "properties": {    "_id": {      "bsonType": "objectId"    },    "name": {      "bsonType": "string"    },    "age": {      "bsonType": "int"    }    "breed": {      "bsonType": "string"    }    "details": {      "bsonType": "mixed"    }  }}

The following code examples create the Dog SDK object model in each of the Atlas Device SDKs.

Dog class defined in Swift SDK data model

import Foundationimport RealmSwiftclass Dog: Object {    @Persisted(primaryKey: true) var _id: ObjectId    @Persisted var age: Int?    @Persisted var breed: String?    @Persisted var name: String = ""    @Persisted var details: AnyRealmValue}

Dog class defined in Java SDK data model

import io.realm.RealmObject;import org.bson.types.ObjectId;public class Dog extends RealmObject {    @PrimaryKey    @Required    private ObjectId _id;    private Integer age;    private String breed;    @Required    private String name;    private RealmAny details;        public ObjectId getId() { return _id; }    public void setId(ObjectId _id) { this._id = _id; }    public Integer getAge() { return age; }    public void setAge(Integer age) { this.age = age; }    public String getBreed() { return breed; }    public void setBreed(String breed) { this.breed = breed; }    public String getName() { return name; }    public void setName(String name) { this.name = name; }    public RealmAny getDetails() { return details; }    public void setDetails(RealmAny details) { this.details = details; }}

Dog class defined in Kotlin SDK data model

import io.realm.RealmObject;import org.bson.types.ObjectId;open class Dog : RealmObject {    @PrimaryKey    var _id: ObjectId = ObjectId(),    var age: Int? = null,    var breed: String? = null,    var name: String = ""    var details: RealmValue? = null}

Dog class defined in Flutter SDK data model

import 'package:realm/realm.dart';part 'realm_models.realm.dart';@RealmModel()class _Dog {  @PrimaryKey()  @MapTo('_id')  late ObjectId id;  int? age;  String? breed;  late String name;  late RealmValue details;}

Dog class defined in .NET SDK data model

using System;using System.Collections.Generic;using Realms;using MongoDB.Bson;public class Dog : RealmObject{    [MapTo("_id")]    [PrimaryKey]    public ObjectId Id { get; set; }    [MapTo("age")]    public int? Age { get; set; }    [MapTo("breed")]    public string Breed { get; set; }    [MapTo("name")]    [Required]    public string Name { get; set; }    [MapTo("details")]    public RealmValue Details { get; set; }}

Dog class defined in Node.js SDK data model

export const DogSchema = {  name: 'Dog',  properties: {    _id: 'objectId',    age: 'int?',    breed: 'string?',    name: 'string',  },  primaryKey: '_id',  details: 'mixed',};

Dog class defined in React Native SDK data model

export const DogSchema = {   class Dog extends Realm.Object<Dog> {     _id!: Realm.BSON.ObjectId;       age?: number;       breed?: string;       name!: string;       details?: Realm.Mixed;     static schema: ObjectSchema = {       name: 'Dog',         properties: {           _id: 'objectId',           age: 'int?',           breed: 'string?',           name: 'string',           details: 'mixed?',         },       primaryKey: '_id',};

An application using Device Sync for the Dog data model creates MongoDB documents in Atlas based on the previous schemas.

Dog document created in Atlas

{  "_id": ObjectId('616f44305a205add93ff1081'),  "age": 8,  "breed": "Golden Retriever",  "name": "Jasper",  "details": null}

Nested collections of mixed data are dictionaries or arrays stored in a mixed data type. This can resemble the following example:

Dog document in MongoDB with mixed data

{  "_id": ObjectId('616f44305a205add93ff1081'),  "age": 8,  "breed": "Golden Retriever",  "name": "Jasper",  "details": {    "vaccinations": ["rabies", "distemper"],    "weight": 65.5,    "isNeutered": true,    "vetVisits": [      {        "date": 2002-08-18T04:56:07.000+00:00,        "reason": "annual checkup"      },      {        "date": 2003-08-18T04:56:07.000+00:00,        "reason": "annual checkup"      }    ]  }}
Note Apps created after May 28, 2024

App Services Apps created after May 28, 2024 can store collections (arrays and dictionaries) of mixed data within a mixed data property. You can nest collections within other collections, which lets you store complex data structures such as JSON or MongoDB documents without having to define a strict data model.

To use this feature with Atlas Device SDK, you must use one of the following minimum SDK versions:

This feature is not supported in the Java SDK.

You can contact Support to learn more about enabling this feature in an existing app using a supported SDK.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4