Atlas Device Sync tiene dos modos de sincronización: Sincronización flexible y la antigua Partition-Based Sync. La sincronización basada en particiones ha quedado obsoleta y no está permitida para nuevas configuraciones de sincronización.
The information on this page is for users who are still using Partition-Based Sync.
Nota
Migrate from Partition-Based Sync to Flexible Sync
Recomendamos migrar las aplicaciones de sincronización basada en particiones a la sincronización flexible. Para obtener más información sobre la migración, consulte Migrar modos de sincronización de dispositivos.
Conceptos clave
En Partition-Based Sync, los documentos en un clúster sincronizado forman una "partición" al tener el mismo valor en un campo designado como "llave de partición". Todos los documentos en una partición tienen los mismos permisos de lectura/guardar para un usuario determinado.
Se define una clave de partición cuyo valor determina si el usuario puede leer o escribir en un documento. App Services evalúa un conjunto de reglas para determinar si los usuarios pueden leer o escribir en una partición determinada. App Services asigna directamente una partición a cada una de las particiones sincronizadas. .realm archivos. Cada objeto en un reino sincronizado tiene un documento correspondiente en la partición.
Ejemplo
Consider an inventory management application using Partition-Based Sync. If you use store_number as the partition key, each store can read and write documents pertaining to its inventory.
Un ejemplo de los permisos para este tipo de aplicación podría ser:
{ "%%partition": "Store 42" }
Los empleados de la tienda podrían tener acceso de lectura y escritura a los documentos cuyo número de tienda sea Tienda 42.
Los clientes, por su parte, podían tener acceso de sólo lectura al inventario de la tienda.
In the client, you pass a value for the partition key when opening a synced realm. App Services then syncs objects whose partition key value matches the value passed in from the client application.
Ejemplo
Según el ejemplo anterior del inventario de la tienda, el SDK podría pasar store42 como partitionValue en la configuración de sincronización. Esto sincronizaría cualquier InventoryItem cuyo partitionValue fuera store42.
You can use custom user data to indicate whether a logged-in user is a store employee or a customer. Store employees would have read and write permission for the store42 data set, while customers would have only read permission for the same data set.
const config = { schema: [InventoryItem], // predefined schema sync: { user: app.currentUser, // already logged in user partitionValue: "store42", }, }; try { const realm = await Realm.open(config); realm.close(); } catch (err) { console.error("failed to open realm", err.message); }
La sincronización de dispositivos requiere clústeres de MongoDB Atlas para ejecutar versiones específicas de MongoDB. La sincronización basada en particiones requiere MongoDB 4.4.0 o superior.
Términos clave
Partición
Una partición es una colección de objetos que comparten el mismo valor de clave de partición.
Un clúster de MongoDB Atlas consta de varios servidores remotos. Estos servidores proporcionan el almacenamiento para los datos sincronizados. El clúster Atlas almacena documentos en colecciones. Cada colección de MongoDB se asigna a un tipo de objeto Realm diferente. Cada documento de una colección representa un objeto Realm específico.
A synced realm is a local file on a device. A synced realm may contain some or all the objects relevant to the end user. A client app may use more than one synced realm to access all the objects that the application needs.
Las particiones vinculan objetos de la base de datos Realm con documentos de MongoDB. Al inicializar un archivo de dominio sincronizado, uno de sus parámetros es un valor de partición. La aplicación cliente crea objetos en el dominio sincronizado. Cuando estos objetos se sincronizan, el valor de partición se convierte en un campo en los documentos de MongoDB. El valor de este campo determina a qué documentos de MongoDB puede acceder el cliente.
A grandes rasgos:
Una partición se asigna a un subconjunto de los documentos en un clúster sincronizado.
Todos los documentos de una partición tienen los mismos permisos de lectura y escritura para un usuario determinado.
Atlas App Services asigna cada partición a un archivo
.realmsincronizado individual.Cada objeto en un realm sincronizado tiene un documento correspondiente en la partición.
Partitions shape data in an Atlas cluster. Each shape represents an object type. Partitions are determined by each shape's color: red, green, or blue.
Clave de partición
Una clave de partición es un campo con nombre que se especifica al configurar Atlas Device Sync. Device Sync utiliza esta clave para determinar qué partición contiene un documento determinado.
Dependiendo de su modelo de datos y la complejidad de su aplicación, su clave de partición podría ser:
Una propiedad que ya existe en cada documento y que particiona los datos de forma lógica. Por ejemplo, considere una aplicación donde cada documento es privado para un usuario específico. Podría almacenar el valor del ID del usuario en un campo
owner_idy usarlo como clave de partición.Una propiedad sintética que se crea para particionar datos (p. ej.,
_partition). Puedes usarla cuando tu aplicación no incluye una clave de partición natural.
Puedes hacer que la llave de partición sea obligatoria u opcional en tus objetos. App Services asigna cualquier objeto que no incluya una llave de partición a una partición predeterminada: partición nula.
Tenga en cuenta lo siguiente al elegir una clave de partición:
Las llaves de partición deben ser de uno de estos tipos:
String,ObjectID,LongoUUID.Los clientes de App Services nunca deben modificar el valor de la partición directamente. No se puede usar ningún campo modificable por los clientes como clave de partición.
Las claves de partición usan el mismo nombre de campo en todos los documentos sincronizados. La clave de partición no debe coincidir con ningún nombre de campo en el modelo de ningún objeto.
Ejemplo
Los siguientes esquemas demuestran claves de partición naturales y sintéticas:
El campo
owner_ides una llave natural porque ya forma parte del modelo de datos de la aplicación.El campo
_partitiones una clave sintética porque su único propósito es servir como clave de partición.
Una aplicación solo puede especificar una única clave de partición, pero cualquiera de estos campos podría funcionar dependiendo de tu caso de uso:
{ "title": "note", "bsonType": "object", "required": [ "_id", "_partition", "owner_id", "text" ], "properties": { "_id": { "bsonType": "objectId" }, "_partition": { "bsonType": "string" }, "owner_id": { "bsonType": "string" }, "text": { "bsonType": "string" } } } { "title": "notebook", "bsonType": "object", "required": [ "_id", "_partition", "owner_id", "notes" ], "properties": { "_id": { "bsonType": "objectId" }, "_partition": { "bsonType": "string" }, "owner_id": { "bsonType": "string" }, "notes": { "bsonType": "array", "items": { "bsonType": "objectId" } } } }
Change a Partition Key
La clave de partición de tu aplicación es fundamental en el modelo de datos de una aplicación con sincronización habilitada. Al configurar una clave de partición en la configuración de sincronización, no podrás reasignar posteriormente el campo de la clave. Si necesitas cambiar una clave de partición, debes finalizar la sincronización. Después, podrás volver a habilitarla con la nueva clave de partición. Sin embargo, esto requiere que todas las aplicaciones cliente se restablezcan y sincronicen los datos en los nuevos dominios.
Advertencia
Restaurar la sincronización después de finalizarla
Al finalizar y reactivar Atlas Device Sync, los clientes ya no podrán sincronizar. Su cliente debe implementar un controlador de restablecimiento de cliente para restaurar la sincronización. Este controlador puede descartar o intentar recuperar los cambios no sincronizados.
valor de la partición
Un valor de la partición es un valor del campo llave de partición para un documento dado. Los documentos con el mismo valor de la partición pertenecen a la misma partición. Se sincronizan con el mismo archivo Realm y comparten permisos de nivel de usuario para acceso a los datos.
A partition's value is the identifier for its corresponding synced realm. You specify the partition's value when you open it as a synced realm in the client. If you change a partition value in Atlas, App Services interprets the change as two operations:
Una eliminación de la partición antigua.
Una inserción en la nueva partición.
Advertencia
Si cambia el valor de partición de un documento, perderá los cambios no sincronizados del lado del cliente en el objeto.
Habilitar la sincronización basada en particiones
Antes de comenzar
Necesitará lo siguiente para habilitar la sincronización basada en particiones:
Una aplicación de App Services. Para aprender cómo crear una aplicación, consulta Crear una aplicación.
Una fuente de datos Atlas vinculada. Para saber cómo agregar una fuente de datos, consulte Vincular una fuente de datos.
Procedimiento
Navegar a la pantalla de configuración de sincronización
Para definir las reglas de sincronización de dispositivos y habilitar la sincronización de dispositivos para su aplicación, navegue hasta la Device Sync Pantalla de configuración a través del menú de navegación izquierdo.
Nota
Las reglas de sincronización no se pueden cambiar
Las reglas de sincronización de dispositivos se definen al mismo tiempo que se habilita. Una vez habilitada, no se pueden cambiar las reglas de sincronización de dispositivos de la aplicación a menos que se cancele y se vuelva a habilitar con nuevas reglas.
Elegir una llave de partición
La clave de partición de Device Sync es un campo en cada documento sincronizado que asigna cada documento a un dominio del cliente. Las reglas de Device Sync se aplican a nivel de partición, por lo que es fundamental considerar el modelo de datos y los patrones de acceso. Para obtener más información sobre las claves de partición y cómo elegir una, consulte Particiones.
Nota
La clave de partición puede ser obligatoria u opcional. Si el campo de clave de partición es opcional, todos los documentos de MongoDB que excluyan la clave de partición o tengan un valor nulo para esta se enviarán a la partición nula. Si el campo de clave de partición es obligatorio, Device Sync ignora cualquier documento de MongoDB que no tenga un valor válido para la clave de partición. Recomendamos una clave de partición obligatoria a menos que desee sincronizar con Device Sync datos preexistentes con valores de partición no válidos o faltantes de una colección de MongoDB.
Definir permisos de lectura y escritura
La Define Permissions sección le permite definir expresiones JSON que App Services evalúa dinámicamente para determinar los permisos de lectura y escritura de un usuario para los datos en una partición determinada.
Las expresiones de regla de sincronización de dispositivos tienen acceso a%%user, que se resuelve al usuario que abrió el dominio, y a%%partition, que se resuelve al valor de la clave de partición del dominio. También puede usar operadores, como%function, para gestionar casos más complejos. Para ver ejemplos, consulte Permisos basados en roles.
Una vez que haya determinado cómo decidir los permisos de lectura y escritura de un usuario para una partición dada, defina las expresiones JSON correspondientes en las entradas Read y Write.
Comprobar comportamientos de configuración avanzada predeterminados
Expandir la sección Advanced Configuration.
Servicios de aplicaciones Las aplicaciones proporcionan funciones de optimización avanzadas que están habilitadas de forma predeterminada:
Si desea cambiar el tiempo que un cliente puede estar sin conexión, puede hacerlo en la sección Advanced Configuration.
Obtenga la última versión de su aplicación
Obtén una copia local de los archivos de configuración de tu aplicación. Para obtener la última versión, ejecuta el siguiente comando:
appservices pull --remote="<Your App ID>"
También puedes exportar una copia de los archivos de configuración de tu aplicación desde la interfaz de usuario o con la API de administración. Para saber cómo, consulta Exportar una aplicación.
Agregar una configuración de sincronización
Puedes habilitar la sincronización para un solo clúster vinculado en tu aplicación.
La aplicación Servicios de aplicaciones tiene un sync directorio donde se encuentra el archivo de configuración de sincronización. Si aún no ha habilitado la sincronización, este directorio está vacío.
Añade un config.json similar a:
{ "type": "partition", "state": <"enabled" | "disabled">, "development_mode_enabled": <Boolean>, "service_name": "<Data Source Name>", "database_name": "<Database Name>", "partition": { "key": "<Partition Key Field Name>", "type": "<Partition Key Type>", "permissions": { "read": { <Expression> }, "write": { <Expression> } } }, "client_max_offline_days": <Number>, "is_recovery_mode_disabled": <Boolean> }
Elegir una llave de partición
La clave de partición de sincronización es un campo en cada documento sincronizado que asigna cada documento a un dominio del lado del cliente. Las reglas de sincronización se aplican a nivel de partición, por lo que es especialmente importante considerar el modelo de datos y los patrones de acceso. Para obtener más información sobre las claves de partición y cómo elegir una, consulte Particiones.
Nota
La clave de partición puede ser obligatoria u opcional. Si el campo de clave de partición es opcional, todos los documentos de MongoDB que excluyan la clave de partición o tengan un valor nulo para esta se enviarán a la partición nula. Si el campo de clave de partición es obligatorio, Device Sync ignora cualquier documento de MongoDB que no tenga un valor válido para la clave de partición. Recomendamos una clave de partición obligatoria a menos que desee sincronizar datos preexistentes con valores de partición no válidos o faltantes de una colección de MongoDB.
Una vez que se haya decidido qué campo utilizar, actualizar sync.partition con el nombre del campo de llave de partición en el campo key y el tipo de llave de partición en el campo type, similar a:
{ ... "partition": { "key": "owner_id", "type": "string", "permissions": { "read": {}, "write": {} } } ... }
Definir permisos de lectura y escritura
App Services le permite definir expresiones JSON que evalúa dinámicamente cada vez que un usuario abre un reino para determinar si el usuario tiene permisos de lectura o escritura para los datos en la partición.
Las expresiones de regla de sincronización tienen acceso a%%user, que se resuelve al usuario que abrió el dominio, y a%%partition, que se resuelve al valor de la clave de partición del dominio. También puede usar operadores, como%function, para gestionar casos más complejos. Para ver ejemplos, consulte Permisos de sincronización.
Once you've determined how to decide a user's read and write permissions for a given partition, define the corresponding JSON expressions in the read and write fields of partition.permissions, similar to:
{ ... "partition": { "key": "owner_id", "type": "string", "permissions": { "read": { "$or": [ { "%%user.id": "%%partition" }, { "%%user.custom_data.shared": "%%partition" } ] }, "write": { "%%user.id": "%%partition" } } } ... }
Especificar valores para la optimización de la sincronización
Sync ofrece funcionalidades para optimizar el rendimiento de Sync y mejorar el proceso de recuperación de datos en el cliente. Estas funcionalidades están representadas por configuraciones adicionales:
client_max_offline_daysis_recovery_mode_disabled
You can set a numerical value for client_max_offline_days. When you enable Sync via the App Services UI, the default value is 30, which represents 30 days.
Para obtener más información, consulte: Tiempo máximo sin conexión del cliente.
El modo de recuperación permite que Sincronización intente recuperar datos que aún no se han sincronizado al restablecer un cliente. Al habilitar Sincronización mediante la interfaz de usuario de App Services, el modo de recuperación se activa de forma predeterminada. Recomendamos activarlo para que el cliente se restablezca automáticamente. Si ha desactivado el modo de recuperación y desea volver a activarlo, configure is_recovery_mode_disabled en false.
Para obtener más información, consulta: Recuperar cambios no sincronizados.
{ "type": "partition", "state": "enabled", "development_mode_enabled": true, "service_name": "mongodb-atlas", "database_name": "my-test-database", "partition": { ... }, "client_max_offline_days": 30, "is_recovery_mode_disabled": false }
Deploy the Sync Configuration
Ahora que ha definido la configuración de sincronización, incluidos los permisos de lectura y escritura, puede implementar los cambios para comenzar a sincronizar datos y aplicar reglas de sincronización.
Para implementar los cambios, importa la configuración de la aplicación en tu App Services Aplicación:
appservices push --remote="<Your App ID>"
Seleccione un clúster para sincronizar
You can enable Sync for a single linked cluster in your application.
Necesitará el archivo de configuración del servicio del clúster para configurar la sincronización. Puede encontrarlo enumerando todos los servicios a través de la API de administración:
curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services \ -X GET \ -h 'Authorization: Bearer <Valid Access Token>'
Identifica el servicio cuya configuración necesitas actualizar para habilitar sincronizar. Si aceptaste los nombres por defecto al configurar tu aplicación, este debería ser un servicio cuyo name es mongodb-atlas y type es mongodb-atlas. Necesitas el/la _id de este servicio.
Ahora puedes obtener el archivo de configuración para este servicio:
curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \ -X GET \ -h 'Authorization: Bearer <Valid Access Token>'
Una vez que tenga la configuración, agregue el objeto sync con la siguiente configuración de plantilla:
{ ... "sync": { "type": "partition", "state": "enabled", "development_mode_enabled": <Boolean>, "database_name": "<Database Name>", "partition": { "key": "<Partition Key Field Name>", "type": "<Partition Key Type>", "permissions": { "read": { <Expression> }, "write": { <Expression> } } }, "client_max_offline_days": <Number>, "is_recovery_mode_disabled": <Boolean> } ... }
Elegir una llave de partición
La clave de partición de sincronización es un campo en cada documento sincronizado que asigna cada documento a un dominio del lado del cliente. Las reglas de sincronización se aplican a nivel de partición, por lo que es especialmente importante considerar el modelo de datos y los patrones de acceso. Para obtener más información sobre las claves de partición y cómo elegir una, consulte Particiones.
You can get a list of all valid partition keys and their corresponding types through the Admin API:
curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/sync/data?service_id=<MongoDB Service ID> \ -X GET \ -h 'Authorization: Bearer <Valid Access Token>'
Nota
La clave de partición puede ser obligatoria u opcional. Si el campo de clave de partición es opcional, todos los documentos de MongoDB que excluyan la clave de partición o tengan un valor nulo para esta se enviarán a la partición nula. Si el campo de clave de partición es obligatorio, Device Sync ignora cualquier documento de MongoDB que no tenga un valor válido para la clave de partición. Recomendamos una clave de partición obligatoria a menos que desee sincronizar datos preexistentes con valores de partición no válidos o faltantes de una colección de MongoDB.
Una vez que haya decidido qué campo utilizar, actualice sync.partition con el nombre del campo de clave de partición en el campo key y el tipo de clave de partición en el campo type.
{ ... "sync": { "type": "partition", "state": "enabled", "development_mode_enabled": <Boolean>, "database_name": "<Database Name>", "partition": { "key": "owner_id", "type": "string", "permissions": { "read": { <Expression> }, "write": { <Expression> } } }, "client_max_offline_days": <Number>, "is_recovery_mode_disabled": <Boolean> } ... }
Definir permisos de lectura y escritura
App Services le permite definir expresiones JSON que evalúa dinámicamente cada vez que un usuario abre un reino para determinar si el usuario tiene permisos de lectura o escritura para los datos en la partición.
Las expresiones de regla de sincronización tienen acceso a%%user, que se resuelve al usuario que abrió el dominio, y a%%partition, que se resuelve al valor de la clave de partición del dominio. También puede usar operadores, como%function, para gestionar casos más complejos. Para ver ejemplos, consulte Permisos de sincronización.
Una vez que haya determinado cómo decidir los permisos de lectura y escritura de un usuario para una partición determinada, defina las expresiones JSON correspondientes en los campos read y write de sync.partition.permissions.
{ ... "sync": { "type": "partition", "state": "enabled", "development_mode_enabled": <Boolean>, "database_name": "<Database Name>", "partition": { "key": "owner_id", "type": "string", "permissions": { "read": { "$or": [ { "%%user.id": "%%partition" }, { "%%user.custom_data.shared": "%%partition" } ] }, "write": { "%%user.id": "%%partition" } } }, "client_max_offline_days": <Number>, "is_recovery_mode_disabled": <Boolean> } ... }
Especificar valores para la optimización de la sincronización
Sync proporciona características que te permiten optimizar el rendimiento de Sync y mejorar el proceso de recuperación de datos del cliente. Estas funcionalidades están representadas por configuraciones adicionales:
client_max_offline_daysis_recovery_mode_disabled
You can set a numerical value for client_max_offline_days. When you enable Sync via the App Services UI, the default value is 30, which represents 30 days.
Para obtener más información, consulte: Tiempo máximo sin conexión del cliente.
El Modo de Recuperación permite a Sync intentar recuperar datos no sincronizados cuando ocurre un reinicio del cliente. Cuando habilitas sincronizar a través de la Interfaz de usuario Realm, el Modo de Recuperación está habilitado por defecto. Recomendamos habilitar el Modo de Recuperación para la gestión automática del restablecimiento del cliente. Para habilitar el Modo de Recuperación, establece is_recovery_mode_disabled en false.
Para obtener más información, consulta: Recuperar cambios no sincronizados.
{ ... "sync": { "type": "partition", "state": "enabled", "development_mode_enabled": true, "database_name": "my-test-database", "partition": { ... }, "client_max_offline_days": 30, "is_recovery_mode_disabled": false } ... }
Deploy the Sync Configuration
Ahora que ha definido la configuración de sincronización, incluidos los permisos de lectura y escritura, puede implementar los cambios para comenzar a sincronizar datos y aplicar reglas de sincronización.
Para implementar sus cambios, envíe una solicitud de API de administración que actualice la configuración del clúster con su configuración de sincronización:
curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \ -X PATCH \ -h 'Authorization: Bearer <Valid Access Token>' \ -d @/sync/config.json
Reglas y permisos basados en particiones
Cada vez que un usuario abre un dominio sincronizado desde una aplicación cliente, App Services evalúa las reglas de la aplicación y determina si el usuario tiene permisos de lectura y escritura para la partición. Los usuarios deben tener permisos de lectura para sincronizar y leer datos en un dominio, y de escritura para crear, modificar o eliminar objetos. El permiso de escritura implica permiso de lectura; por lo tanto, si un usuario tiene permiso de escritura, también tiene permiso de lectura.
Comportamiento de las reglas de sincronización basadas en particiones
Las reglas de sincronización se aplican a particiones específicas y se vinculan al modelo de datos de la aplicación mediante la clave de partición. Tenga en cuenta el siguiente comportamiento al diseñar sus esquemas para garantizar la granularidad adecuada en el acceso a los datos y evitar la filtración accidental de información confidencial.
Las reglas de sincronización se aplican dinámicamente según el usuario. Un usuario puede tener acceso completo de lectura y escritura a una partición, mientras que otro solo tiene permisos de lectura o no puede acceder a ella por completo. Estos permisos se controlan mediante la definición de expresiones JSON.
Sync rules apply equally to all objects in a partition. If a user has read or write permission for a given partition then they can read or modify all synced fields of any object in the partition.
Los permisos de guardado requieren permisos de lectura; por lo tanto, un usuario con acceso de guardado a una partición también puede leer independientemente de las reglas de permisos de lectura definidas.
Permisos de sincronización basados en particiones
Los Servicios de aplicación aplican permisos dinámicos de lectura y guardar específicos del usuario para proteger los datos en cada partición. Defines los permisos con expresiones de Expresión de regla JSON que controlan si un usuario determinado tiene acceso de lectura o escritura a los datos en una partición determinada. aplicación Services evalúa los permisos de un usuario cada vez que abre un realm sincronizado.
Tip
Sus Expresiones de regla pueden utilizar expansiones JSON como %%partition y %%user para determinar dinámicamente los permisos de un usuario basándose en el contexto de su solicitud.
Conceptos clave
Read Permissions
A user with read permissions for a given partition can view all fields of any object in the corresponding synced realm. Read permissions do not permit a user to modify data.
Permisos de escritura
Un usuario con permisos de guardar para una partición dada puede modificar el valor de cualquier campo de cualquier objeto en el realm sincronizado correspondiente. Los permisos de guardar requieren permisos de lectura, por lo que cualquier usuario que pueda modificar datos también podrá ver esos datos antes y después de modificarlos.
Estrategias de permisos
Importante
Las relaciones no pueden abarcar particiones
In an app that uses Partition-Based Sync, an object can only have a relationship with other objects in the same partition. The objects can exist in different databases and collections (within the same cluster) as long as the partition key value matches.
Puedes estructurar tus expresiones de permisos de lectura y escritura como un conjunto de estrategias de permisos que se aplican a tu estrategia de partición. Las siguientes estrategias describen enfoques comunes que puedes utilizar para definir permisos de lectura y escritura sincronizados para tu aplicación.
Permisos globales
Puede definir permisos globales que se apliquen a todos los usuarios en todas las particiones. En esencia, esto implica optar por no implementar permisos específicos de usuario y, en cambio, por permisos universales de lectura o escritura que se apliquen a todos los usuarios.
Para definir un permiso global de lectura o escritura, especifique un valor booleano o una expresión JSON que siempre evalúe el mismo valor booleano.
Ejemplo | Descripción | |
|---|---|---|
| La expresión | |
| La expresión | |
| Esta expresión siempre se evalúa como |
Permisos para particiones específicas
You can define permissions that apply to a specific partition or a groups of partitions by explicitly specifying their partition values.
Ejemplo | Descripción | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| This expression means that all users have the given access permissions for data with a partition value of | |||||||||
| Esta expresión significa que todos los usuarios tienen los permisos de acceso dados para los datos con cualquiera de los valores de partición especificados. |
Permisos para usuarios específicos
Puedes definir permisos que apliquen a un usuario específico o a un grupo de usuarios especificando explícitamente sus valores ID.
Ejemplo | Descripción | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Esta expresión significa que el usuario con id | |||||||||
| Esta expresión significa que cualquier usuario con uno de los valores de ID de usuario especificados tiene los permisos de acceso dados para los datos en cualquier partición. |
Permissions Based on User Data
Puede definir permisos que se apliquen a los usuarios en función de datos específicos definidos en su documento de datos de usuario personalizado, campos de metadatos u otros datos de un proveedor de autenticación.
Ejemplo | Descripción | |
|---|---|---|
| This expression means that a user has read access to a partition if the partition value is listed in the | |
| Esta expresión significa que un usuario tiene acceso de escritura a una partición si el valor de la partición aparece en el campo |
Reglas de función
Puedes definir permisos dinámicos complejos evaluando una función que retorna un valor booleano. Esto resulta útil en esquemas de permisos que requieren acceder a sistemas externos u otra lógica personalizada que no se puede expresar únicamente en expresiones JSON.
Ejemplo | Descripción | |||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Esta expresión llama a la función |
Migrar reglas de sincronización basadas en particiones a reglas de App Services
Si migra su aplicación de sincronización basada en particiones a sincronización flexible, sus reglas de acceso a datos también deben migrarse.
Algunas estrategias de reglas de sincronización basadas en particiones no se pueden traducir directamente a reglas de App Services. Es posible que deba migrar manualmente los permisos que incluyen:
%functionoperador.Function rules are not compatible with Flexible Sync and cannot be migrated.
%%partitionexpansion.Las reglas de servicios de aplicaciones no tienen una expansión equivalente
%%partitionpara, por lo que no se pueden migrar.%or,%not,%nor,%andexpansions.These permissions may work, but there is enough nuance that you should test them to ensure expected behavior. Testing new permissions won't work on the App you are migrating. You'll need a new app to test manually-migrated permissions.
Consulte la lista de expansiones compatibles con Flexible Sync para ver todas las expansiones admitidas.
You should also check out the Device Sync Permissions Guide for more information about how to work with permissions.
Estrategias de partición
Una estrategia de partición es un patrón clave/valor para dividir objetos en particiones. Diferentes casos de uso requieren diferentes estrategias de partición. Puedes combinar estrategias de partición dentro de la misma aplicación para formar una estrategia más amplia. Esto le permite gestionar casos de uso arbitrariamente complejos.
La estrategia a utilizar depende del modelo de datos y de los patrones de acceso de tu aplicación. Considera una aplicación con datos tanto públicos como privados. Podrías colocar algunos datos, como anuncios, en una partición pública. Podrías restringir otros datos, como información personal, a usuarios privilegiados.
When developing a partition strategy, consider:
Seguridad de datos: Los usuarios pueden necesitar diferentes permisos de lectura y escritura para subconjuntos de datos. Considere los permisos que necesitan los usuarios para cada tipo de documento. Un usuario tiene los mismos permisos para todos los documentos de una partición.
Capacidad de almacenamiento: Tus aplicaciones cliente pueden tener almacenamiento limitado en el dispositivo en algunas plataformas y dispositivos. Una estrategia de partición debe tener en cuenta las limitaciones de almacenamiento. Asegúrate de que un usuario pueda almacenar sus datos sincronizados en su dispositivo.
Tip
Combinar estrategias
You can use a partition key name like _partition with a query string as the value. This lets you use multiple strategies in the same app. For example:
_partitionKey: "user_id=abcdefg" _partitionKey: "team_id=1234&city='New York, NY'"
You can use functions and rule expressions to parse the string. Sync can determine whether a user has access to a partition based on the combined strategy.
Estrategia de manguera contra incendios
Una estrategia de partición Firehose agrupa todos los documentos en una sola partición. Con esta estructura, cada usuario sincroniza todos los datos de la aplicación con su dispositivo. Este enfoque, en la práctica, implica no particionar los datos. Funciona para aplicaciones básicas o pequeños conjuntos de datos públicos.
Data Security. All data is public to clients with a realm that uses the partition. If a user has read or write access to the partition, they can read or write any document.
Capacidad de almacenamiento. Cada usuario sincroniza cada documento en la partición. Todos los datos deben caber dentro de tu limitación de almacenamiento más restrictiva. Utiliza esta estrategia solo cuando los conjuntos de datos sean pequeños y no crezcan rápidamente.
Una forma de crear una manguera contra incendios es establecer la clave de partición como campo opcional. No incluya un valor para este campo en ningún documento. App Services asigna cualquier documento que no incluya un valor de partición a la partición nula.
You can also set a static partition value. This is when the partition value doesn't change based on the user or data. For example, realms across all clients could use the partition value "MyPartitionValue".
Ejemplo
Una aplicación permite a los usuarios consultar los resultados y las estadísticas de los partidos de béisbol de las escuelas secundarias locales. Considere los siguientes documentos en las colecciones games y teams:
collection games: [ { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... } { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... } { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... } { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... } { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... } { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... } ] collection teams: [ { name: "Brook Ridge Miners" } { name: "Southside Rockets" } { name: "Uptown Bombers" } ]
The total number of games is small. A small number of local teams only play a few games each year. Most devices should be able to download all game data for easy offline access. In this case, the firehose strategy is appropriate. The data is public and documents don't need a partition key.
La estrategia asigna las colecciones a los siguientes ámbitos:
realm null: [ Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... } Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... } Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... } Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... } Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... } Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... } Team { name: "Brook Ridge Miners" } Team { name: "Southside Rockets" } Team { name: "Uptown Bombers" } ]
User Strategy
Una estrategia de partición de usuario agrupa documentos privados para cada usuario. Estos documentos van en una partición específica de ese usuario. Esto funciona cuando cada documento tiene un propietario y nadie más necesita los datos. Un nombre de usuario o un ID que identifique al propietario hace que una clave de partición sea natural.
Seguridad de datos. Los datos en una partición de usuario son específicos para un usuario dado. Puede contener información privada de ese usuario. Cada usuario sincroniza solo su propia partición. Otros usuarios no pueden acceder a los documentos en la partición.
Capacidad de almacenamiento. Cada usuario sólo sincroniza los datos de su propia partición. Sus datos deben caber dentro de las restricciones de almacenamiento de su dispositivo. Usa esta estrategia sólo cuando cada usuario tenga una cantidad manejable de datos.
Ejemplo
Una aplicación de streaming de música almacena datos sobre listas de reproducción y calificaciones de canciones de cada usuario. Considere los siguientes documentos en las colecciones playlists y ratings:
collection playlists: [ { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] } { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] } { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] } { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] } { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] } ] collection ratings: [ { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 } { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 } { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 } ]
Cada documento incluye el campo owner_id. Esta es una buena clave de partición para una estrategia de partición de usuarios. Asigna los documentos a usuarios individuales de forma natural. Esto limita los datos de cada dispositivo a las listas de reproducción y las calificaciones del usuario.
Los usuarios tienen acceso de lectura y escritura a su dominio de usuario. Este contiene las listas de reproducción que han creado y las calificaciones que han otorgado a las canciones.
Cada usuario tiene acceso de lectura al dominio para la partición
PUBLIC. Esta contiene listas de reproducción disponibles para todos los usuarios.
La estrategia asigna las colecciones a los siguientes ámbitos:
realm dog_enthusiast_95: [ Playlist { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] } Playlist { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] } Rating { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 } Rating { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 } ] realm cat_enthusiast_92: [ Playlist { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] } Rating { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 } ] realm PUBLIC: [ Playlist { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] } Playlist { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] } ]
Team Strategy
Una estrategia de partición de equipo agrupa documentos privados compartidos por un equipo de usuarios. Un equipo puede incluir a los empleados de una tienda o a los miembros de una banda. Cada equipo tiene una partición específica. Todos los usuarios del equipo comparten el acceso y la propiedad de los documentos.
Data Security. Data in a team partition is specific to a given team. It may contain data private to the team but not to a member of the team. Each user syncs partitions for the teams they belong to. Users not in a team cannot access documents in the team's partition.
Capacidad de almacenamiento: Cada usuario solo sincroniza los datos de sus propios equipos. Los datos de los equipos de un usuario deben ajustarse a las limitaciones de almacenamiento de su dispositivo. Utilice esta estrategia cuando los usuarios pertenezcan a un número razonable de equipos. Si los usuarios pertenecen a varios equipos, los dominios combinados podrían contener una gran cantidad de datos. Es posible que deba limitar el número de particiones de equipo que se sincronizan simultáneamente.
Ejemplo
An app lets users create projects to collaborate with other users. Consider the following documents in the projects and tasks collections:
collection projects: [ { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] } { name: "API", owner_id: "api-team", task_ids: [ ... ] } ] collection tasks: [ { status: "complete", owner_id: "api-team", text: "Import dependencies" } { status: "inProgress", owner_id: "api-team", text: "Create app MVP" } { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" } { status: "todo", owner_id: "api-team", text: "Write tests" } { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" } { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" } ]
Cada documento incluye el campo owner_id. Esta es una buena clave de partición para una estrategia de partición de equipos. Asigna documentos a equipos individuales de forma natural. Esto limita los datos en cada dispositivo. Los usuarios solo tienen proyectos y tareas relevantes para ellos.
Users have read and write access to partitions owned by teams where they're a member.
Los datos almacenados en una colección
teamsouserspueden asignar usuarios a la membresía del equipo:collection teams: [ { name: "cli-team", member_ids: [ ... ] } { name: "api-team", member_ids: [ ... ] } ] collection users: [ { name: "Joe", team_ids: [ ... ] } { name: "Liz", team_ids: [ ... ] } { name: "Matt", team_ids: [ ... ] } { name: "Emmy", team_ids: [ ... ] } { name: "Scott", team_ids: [ ... ] } ]
La estrategia asigna las colecciones a los siguientes ámbitos:
realm cli-team: [ Project { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] } Task { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" } Task { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" } ] realm api-team: [ Project { name: "API", owner_id: "api-team", task_ids: [ ... ] } Task { status: "complete", owner_id: "api-team", text: "Import dependencies" } Task { status: "inProgress", owner_id: "api-team", text: "Create app MVP" } Task { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" } Task { status: "todo", owner_id: "api-team", text: "Write tests" } ]
Estrategia de canal
Una estrategia de partición de canal agrupa documentos para un tema o dominio común. Cada tema o dominio tiene su propia partición. Los usuarios pueden elegir acceder o suscribirse a canales específicos. Un nombre o ID puede identificar estos canales en una lista pública.
Seguridad de datos. Los datos de una partición de canal son específicos de un tema o área. Los usuarios pueden elegir acceder a estos canales. Puede limitar el acceso de un usuario a un subconjunto de canales. También puede impedir que los usuarios accedan a los canales por completo. Si un usuario tiene permiso de lectura o escritura en un canal, puede acceder a cualquier documento de la partición.
Capacidad de almacenamiento. Los usuarios pueden sincronizar datos desde cualquier canal permitido. Todos los datos de los canales de un usuario deben ajustarse a las limitaciones de almacenamiento de su dispositivo. Utilice esta estrategia para particionar conjuntos de datos públicos o semiprivados. Esta estrategia divide los conjuntos de datos que no se ajustan a las limitaciones de almacenamiento.
Ejemplo
An app lets users create chatrooms based on topics. Users can search for and join channels for any topic that interests them. Consider these documents in the chatrooms and messages collections:
collection chatrooms: [ { topic: "cats", description: "A place to talk about cats" } { topic: "sports", description: "We like sports and we don't care who knows" } ] collection messages: [ { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 } { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 } { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 } { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 } { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 } ]
Cada documento incluye el campo topic. Esta es una buena clave de partición para una estrategia de partición de canales. Asigna documentos a canales individuales de forma natural. Esto reduce los datos en cada dispositivo. Los datos solo contienen mensajes y metadatos de los canales que el usuario ha seleccionado.
Los usuarios tienen acceso de lectura y escritura en las salas de chat donde están suscritos. Los usuarios pueden cambiar o borrar cualquier mensaje, incluso los enviados por otros usuarios. Para limitar los permisos de guardado, puedes darles a los usuarios acceso solo de lectura. Luego, gestionar el envío de mensajes con una función sin servidor.
Store the use's subscribed channels in either the
chatroomsoruserscollection:collection chatrooms: [ { topic: "cats", subscriber_ids: [ ... ] } { topic: "sports", subscriber_ids: [ ... ] } ] collection users: [ { name: "Joe", chatroom_ids: [ ... ] } { name: "Liz", chatroom_ids: [ ... ] } { name: "Matt", chatroom_ids: [ ... ] } { name: "Emmy", chatroom_ids: [ ... ] } { name: "Scott", chatroom_ids: [ ... ] } ]
La estrategia asigna las colecciones a los siguientes ámbitos:
realm cats: [ Chatroom { topic: "cats", description: "A place to talk about cats" } Message { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 } Message { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 } ] realm sports: [ Chatroom { topic: "sports", description: "We like sports and we don't care who knows" } Message { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 } Message { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 } Message { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 } ]
Estrategia de región
Una estrategia de partición regional agrupa documentos relacionados con una ubicación o región. Cada partición contiene documentos específicos de esas áreas.
Seguridad de los datos. Los datos son específicos de una determinada área geográfica. Puede limitar el acceso de un usuario a su región actual. Alternativamente, conceda acceso a los datos por región.
Capacidad de almacenamiento. Las necesidades de almacenamiento varían según el tamaño y los patrones de uso de la región. Es posible que los usuarios solo sincronicen datos en su propia región. Los datos de cualquier región deben ajustarse a las limitaciones de almacenamiento del dispositivo. Si los usuarios sincronizan varias regiones, divídanlas en subregiones más pequeñas. Esto ayuda a evitar sincronizar datos innecesarios.
Ejemplo
An app lets users search for nearby restaurants and order from their menus. Consider the following documents in the restaurants collection:
collection restaurants: [ { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] } { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] } { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] } { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] } { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ] } { city: "Chicago, IL", name: "Nando's", menu: [ ... ] } ]
Cada documento incluye el campo city. Esta es una buena llave de partición para una estrategia de particionamiento de región. Asocia de manera natural los documentos con áreas físicas específicas. Esto limita los datos a mensajes y metadatos de la ciudad actual del usuario. Los usuarios tienen acceso de lectura a restaurantes en su región actual. Se podría determinar la región del usuario en la lógica de la aplicación.
La estrategia asigna las colecciones a los siguientes ámbitos:
realm New York, NY: [ { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] } { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] } { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] } ] realm Chicago, IL: [ { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] } { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ] } { city: "Chicago, IL", name: "Nando's", menu: [ ... ] } ]
Estrategia de depósito
Una estrategia de partición de buckets agrupa los documentos por rango. Cuando los documentos se extienden a lo largo de una dimensión, una partición contiene un subrango. Considere rangos de buckets basados en el tiempo. Los desencadenadores mueven los documentos a nuevas particiones cuando caen fuera de su rango de bucket.
Data Security. Limit users to read or write only specific buckets. Data may flow between buckets. Consider access permissions for a document across all possible buckets.
Capacidad de almacenamiento. Las necesidades de almacenamiento varían según el tamaño y los patrones de uso de cada bucket. Considere a qué buckets necesitan acceder los usuarios. Limite el tamaño de los buckets para que se ajuste a las limitaciones de almacenamiento del dispositivo. Si los usuarios sincronizan muchos buckets, divídalos en buckets más pequeños. Esto ayuda a evitar la sincronización de datos innecesarios.
Ejemplo
Una aplicación de IoT muestra vistas en tiempo real de las lecturas de los sensores varias veces por segundo. Los intervalos se calculan a partir de la cantidad de segundos transcurridos desde la recepción de la lectura. Considere estos documentos en la colección readings:
collection readings: [ { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } } { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } } { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } } { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } } { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } } ]
Cada documento incluye el campo bucket. Este campo asigna los documentos a intervalos de tiempo específicos. El dispositivo del usuario solo contiene las lecturas de los sensores de la ventana que visualiza.
Users have read access to sensor readings for any time bucket.
Sensors use client apps with write access to upload readings.
La estrategia asigna las colecciones a los siguientes ámbitos:
realm 0s<t<=60s: [ Reading { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } } Reading { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } } Reading { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } } ] realm 60s<t<=300s: [ Reading { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } } Reading { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } } ]
Data Ingest
Data Ingest is a feature of Flexible Sync and cannot be enabled on apps that use Partition-Based Sync.
Partition-Based Sync Configuration
Cuando utilices Sync basado en particiones, tu aplicación Atlas App Services utiliza esta configuración de sincronizar:
{ "type": "partition", "state": <"enabled" | "disabled">, "development_mode_enabled": <Boolean>, "service_name": "<Data Source Name>", "database_name": "<Development Mode Database Name>", "partition": { "key": "<Partition Key Field Name>", "type": "<Partition Key Type>", "permissions": { "read": { <Expression> }, "write": { <Expression> } } }, "last_disabled": <Number>, "client_max_offline_days": <Number>, "is_recovery_mode_disabled": <Boolean> }
Campo | Descripción |
|---|---|
typeString | El modo de sincronización. Hay dos modos de sincronizar: Flexible Sync y el antiguo Sync basado en particiones. Opciones válidas para una configuración de sincronización basada en particiones:
|
stateString | El estado actual del protocolo de sincronización para la aplicación. Opciones válidas:
|
service_nameString | El nombre de la fuente de datos de MongoDB que se sincronizará. No se puede usar la sincronización con una instancia sin servidor ni con una instancia de base de datos federada. |
development_mode_enabledBoolean | Si |
database_nameString | El nombre de una base de datos en el clúster sincronizado donde App Services almacena datos en modo de desarrollo. App Services genera automáticamente un esquema para cada tipo sincronizado y asigna cada tipo de objeto a una colección dentro de la base de datos. |
partition.keyString | El nombre del campo de la llave de partición de tu aplicación. Este campo debe estar definido en el esquema para los tipos de objetos que deseas sincronizar. |
partition.typeString | El tipo de valor del campo de llave de partición. Esto debe coincidir con el tipo definido en el esquema del objeto. Opciones válidas:
|
partition.permissions.readExpression | Una expresión que evalúa a |
partition.permissions.writeExpression | Una expresión que evalúa a |
last_disabledNumber | La fecha y hora en que la sincronización fue pausada o desactivada por última vez, se representa por el número de segundos transcurridos desde la Unix epoch (1 de enero de 1970, 00:00:00 UTC). |
client_max_offline_daysNumber | Controla cuánto tiempo espera el proceso de compactación de backend antes de eliminar agresivamente los metadatos que algunos clientes requieren para sincronizarse desde una versión antigua de un realm. |
is_recovery_mode_disabledBoolean | Si |
Modificar la configuración de sincronización basada en particiones
Debes Terminar Device Sync y Volver a habilitar Device Sync para realizar cambios en tu configuración de sincronización de dispositivos basada en particiones. Mientras vuelves a habilitar Atlas Device Sync, puedes especificar una nueva clave de partición o realizar cambios en tus permisos de lectura/escritura. Realizar cambios en tu configuración de Device Sync mientras terminas y vuelves a habilitar Device Sync activará un restablecimiento del cliente. Para saber más sobre cómo lidiar con los restablecimientos del cliente, lee la documentación de restablecimiento del cliente.
Partition-Based Sync Errors
Pueden producirse los siguientes errores cuando la aplicación utiliza Partition-Based Sync.
Nombre del error | Descripción |
|---|---|
ErrorIllegalRealmPath | Este error indica que el cliente intentó abrir un dominio con un valor de partición de tipo incorrecto. Por ejemplo, podría aparecer el mensaje de error "Intento de enlace en una partición de dominio ilegal: se esperaba que la partición tuviera el tipo objectId, pero se encontró una cadena". Para recuperarse de este error, asegúrese de que el tipo de valor de partición utilizado para abrir el reino coincida con el tipo de clave de partición en su configuración de sincronización de dispositivo. |
Compactación de backend
Atlas Device Sync utiliza espacio en el clúster Atlas sincronizado de tu aplicación para almacenar metadatos para la sincronización. Esto incluye un historial de cambios en cada dominio. Atlas App Services minimiza este uso de espacio en tu clúster Atlas. Minimizar los metadatos es necesario para reducir el tiempo y los datos necesarios para la sincronización.
Las aplicaciones que utilizan la sincronización basada en particiones realizan una compactación del backend para reducir la cantidad de metadatos almacenados en un clúster Atlas. La compactación del backend es un proceso de mantenimiento que se ejecuta automáticamente para todas las aplicaciones que utilizan la sincronización basada en particiones. Mediante la compactación, el backend optimiza el historial de un dominio eliminando metadatos innecesarios del conjunto de cambios. El proceso elimina cualquier instrucción cuyo efecto se sobrescriba posteriormente con una instrucción más reciente.
Ejemplo
Consider the following realm history:
CREATE table1.object1 UPDATE table1.object1.x = 4 UPDATE table1.object1.x = 10 UPDATE table1.object1.x = 42
La siguiente historia también convergería al mismo estado, pero sin cambios intermedios innecesarios:
CREATE table1.object1 UPDATE table1.object1.x = 42
Nota
La sincronización basada en particiones utiliza la compactación del backend para reducir el historial de sincronización de dispositivos almacenado en Atlas. La sincronización flexible logra esto mediante la optimización y el tiempo máximo sin conexión del cliente.