Actualice su modelo de datos

Cambios radicales

Es difícil implementar cambios de esquema innovadores, ya que los clientes antiguos (aquellos que no se han actualizado al nuevo código y esquema) aún necesitan acceder a los datos mediante la definición del esquema anterior. Los clientes actualizados deben trabajar con los nuevos cambios de esquema.

Referencia rápida sobre cambios disruptivos y no disruptivos

Un cambio disruptivo es un cambio que se realiza en el esquema del servidor y que requiere una acción adicional para gestionarse. Un cambio disruptivo en el esquema del servidor requiere que se finalice la sincronización en el backend y luego se vuelva a habilitar. Los cambios disruptivos en el esquema provocan que los clientes no puedan abrir un dominio o que se produzca una pérdida de datos cuando los documentos del servidor no se sincronizan con las aplicaciones del cliente. Impiden que las aplicaciones se recuperen automáticamente tras un restablecimiento del cliente.

Un cambio permanente es un cambio que se puede realizar en el esquema del servidor o en el modelo de objetos sin necesidad de gestión adicional en la aplicación. También conocidos como cambios aditivos, se aplican automáticamente a los dominios sincronizados.

Nota

Aplicar cambios no disruptivos al cliente puede requerir una migración

Si solo realiza cambios permanentes en el esquema del servidor, no se requiere ninguna acción adicional. Sin embargo, si intenta aplicar estos cambios al modelo de objetos del cliente, podría necesitar una migración. Si el dispositivo cliente ya tiene un archivo de dominio, deberá realizar una migración. Para obtener más información, consulte la página "Modificar un esquema de objeto" en su SDK preferido.

El siguiente diagrama muestra los tipos de cambios de esquema que puede realizar y el proceso que sigue para realizarlos. Cada uno de estos cambios se explica con más detalle en la tabla y las secciones siguientes.

Esta tabla resume cada tipo de cambio y si es un cambio crítico o un cambio no disruptivo.

Tipo de cambio	Esquema del lado del servidor	Modelo de objetos del lado del cliente
Agregar un tipo de objeto	Irrompible	Irrompible
Agregar un valor predeterminado a una propiedad	Irrompible	Irrompible
Agregar una propiedad requerida	Irrompible	Irrompible
Agregar una propiedad opcional	Irrompible	Irrompible
Eliminar un tipo de objeto	Rompiendo	Irrompible
Eliminar una propiedad opcional u obligatoria	Rompiendo	Irrompible
Cambiar el nombre de un tipo de objeto	Rotura*	Rotura*
Cambiar el nombre de una propiedad	Rotura*	Rotura*
Cambiar el tipo de propiedad pero conservar el nombre	Rompiendo	Rompiendo
Cambiar el estado de la propiedad entre opcional y obligatorio	Rompiendo	Rompiendo

Tip

Cambiar el nombre de una propiedad

Si bien cambiar el nombre de una propiedad u objeto es un cambio radical, algunos SDK de Realm ofrecen una solución alternativa para reasignar el nombre de la propiedad. Consulte Cambiar el nombre de una propiedad para obtener más detalles.

Agregar un tipo de objeto

Puede agregar un tipo de objeto al esquema del lado del servidor o al modelo de objetos del cliente sin realizar ninguna manipulación adicional.

Si desea agregar un tipo de objeto tanto al esquema del servidor como al modelo de objetos del cliente, puede agregarlo al modelo de objetos y usar el modo de desarrollo para que App Services gestione las actualizaciones del esquema del servidor. También puede agregarlo manualmente tanto al modelo como al esquema.

Agregar un valor predeterminado a una propiedad

Puede agregar un valor predeterminado a la propiedad requerida de un objeto. Al insertar en la colección un documento de Atlas que no tenga esta propiedad requerida, los clientes de Realm la establecen con el valor predeterminado. Sin embargo, la misma propiedad del documento de Atlas permanece vacía hasta que un cliente la modifique o actualice el documento directamente en Atlas.

Para obtener más información sobre cómo los valores predeterminados son útiles al modificar documentos Atlas existentes,consulte Agregar una propiedad requerida.

Agregar una propiedad requerida

Puede agregar una propiedad obligatoria al modelo de objetos del cliente y usar el modo de desarrollo para que App Services infiera las actualizaciones del esquema del servidor. También puede agregar manualmente la propiedad obligatoria tanto al modelo del cliente como al esquema de Atlas. Sin embargo, considere hacer la propiedad opcional para evitar tener que modificar los documentos de Atlas existentes.

Agregar una propiedad opcional

Si desea agregar una propiedad opcional tanto al esquema del servidor como al modelo de objetos del cliente, puede agregarla al modelo de objetos y usar el modo de desarrollo para que App Services infiera las actualizaciones del esquema del servidor. También puede agregarla manualmente tanto al modelo como al esquema.

Eliminar un tipo de objeto

Puede eliminar un objeto del modelo de objetos del cliente como un cambio permanente. Si elimina el objeto del esquema del servidor, se considera un cambio importante. Por este motivo, le recomendamos eliminar el tipo de objeto únicamente del modelo de objetos del cliente y dejarlo en el esquema del servidor.

Eliminar una propiedad

Puede eliminar una propiedad opcional u obligatoria del modelo de objetos del cliente y dejarla intacta en el esquema del servidor. Este cambio es permanente en el modelo de objetos.

Si elimina una propiedad del esquema del servidor, se trata de un cambio importante. Por este motivo, recomendamos eliminarla únicamente del modelo de objetos del cliente y dejarla en el esquema del servidor.

Para mantener la compatibilidad con versiones anteriores, eliminar una propiedad de un modelo de objetos del lado del cliente no la elimina de la base de datos. En su lugar, los objetos nuevos conservan la propiedad eliminada y App Services establece el valor en un valor vacío adecuado, como null para propiedades que aceptan valores NULL, 0 para valores enteros o una cadena vacía para valores de cadena.

Cambiar el nombre de un objeto

Cambiar el nombre de un objeto, tanto en el esquema del servidor como en el modelo de objetos del cliente, supone un cambio radical. Sin embargo, algunos SDK ofrecen una API para asignar un nuevo nombre de objeto a un nombre existente en el esquema. Esto permite cambiar el nombre de un objeto en el cliente, pero no en el servidor. De esta forma, se evita la migración. La asignación de nombres de objetos es compatible con los siguientes SDK:

• Kotlin

• Java

• .NET

• Aleteo

Si la asignación de nombres no es una opción, considere implementar una estrategia de recopilación de socios, en la que conserve la recopilación y el esquema existentes y cree una nueva recopilación con el nuevo esquema.

Si decide cambiar el nombre del objeto en lugar de usar la estrategia de recopilación de socios, debe finalizar la sincronización, actualizar manualmente el esquema y volver a habilitarla. Además, la aplicación cliente debe reiniciar el cliente para restaurar la sincronización. En el modo de reinicio predeterminado, el cliente intenta recuperar los cambios no sincronizados antes de reiniciar.

Cambiar el nombre de una propiedad

Cambiar el nombre de una propiedad, tanto en el esquema del servidor como en el modelo de objetos del cliente, supone un cambio radical. Sin embargo, algunos SDK ofrecen una API para asignar un nuevo nombre de propiedad a un nombre existente en el esquema. Esto permite cambiar el nombre de una propiedad en el cliente, pero no en el servidor. De esta forma, se evita la migración. La asignación de nombres de propiedad es compatible con los siguientes SDK:

• Flutter: Reasignar una propiedad

• Java: Cambiar el nombre de un campo

• Kotlin: Remapear una propiedad

• .NET: Cambiar el nombre de una propiedad

• Node.js: Reasignar una propiedad

• React Native: Reasignar una propiedad

• Swift: Reasignar una propiedad

Si la asignación de nombres no es una opción, considere implementar una estrategia de recopilación de socios, en la que conserve la recopilación y el esquema existentes y cree una nueva recopilación con el nuevo esquema.

Si decide cambiar el nombre de la propiedad en lugar de usar la estrategia de recopilación de socios, debe finalizar la sincronización, actualizar manualmente el esquema y volver a habilitarla. Además, la aplicación cliente debe realizar un restablecimiento del cliente para restaurar la sincronización. En el modo de restablecimiento predeterminado, el cliente intenta recuperar los cambios no sincronizados antes de reiniciar.

Al finalizar y reactivar la sincronización, también debe actualizar los documentos Atlas existentes para que se sincronicen con las aplicaciones cliente. Sin esta gestión adicional, dichos documentos no se sincronizan y el cliente podría indicar que se han perdido los datos. Puede resolver este problema de dos maneras:

• Cambie el nombre del campo antiguo en cada documento para que coincida con el nuevo esquema

• Agregue un nuevo campo a cada documento con un nombre que coincida con el nuevo esquema y copie el valor del campo antiguo en él.

Después de realizar estos cambios, los documentos correspondientes se sincronizarán con la aplicación cliente.

Cambiar un tipo de propiedad pero conservar el nombre

Cambiar el tipo de una propiedad es un cambio radical tanto para el esquema del lado del servidor como para el modelo de objetos del lado del cliente.

En lugar de cambiar el tipo de una propiedad, considere implementar la estrategia de recopilación de socios, en la que conserva la recopilación y el esquema existentes y crea una nueva recopilación con el nuevo esquema.

Si decide cambiar el tipo de propiedad en lugar de usar la estrategia de recopilación de socios, debe finalizar la sincronización, actualizar manualmente el esquema y volver a habilitarla. Además, la aplicación cliente debe realizar un restablecimiento del cliente para restaurar la sincronización. En el modo de restablecimiento predeterminado, el cliente intenta recuperar los cambios no sincronizados antes de reiniciar.

Al finalizar y reactivar la sincronización, también debe actualizar los documentos Atlas existentes para que se sincronicen con las aplicaciones cliente. Sin esta gestión adicional, dichos documentos no se sincronizan y el cliente podría indicar que se han perdido los datos. Puede resolver este problema de dos maneras:

• Cambiar el tipo de campo antiguo en cada documento para que coincida con el nuevo esquema

• Agregue un nuevo campo a cada documento con el tipo que coincida con el nuevo esquema y copie el valor del campo antiguo en él, transformando su tipo.

Después de realizar estos cambios, los documentos apropiados deberían sincronizarse nuevamente con la aplicación cliente.

Cambiar el estado de una propiedad entre opcional y obligatorio

Cambiar el estado de una propiedad entre opcional y obligatorio es un cambio radical tanto para el esquema del lado del servidor como para el modelo de objetos del lado del cliente.

En lugar de cambiar el estado de una propiedad, considere implementar la estrategia de recopilación de socios, en la que conserva la recopilación y el esquema existentes y crea una nueva recopilación con el nuevo esquema.

Si decide cambiar el estado de la propiedad en lugar de usar la estrategia de recopilación de socios, debe finalizar la sincronización, actualizar manualmente el esquema y volver a habilitarla. Además, la aplicación cliente debe realizar un restablecimiento del cliente para restaurar la sincronización. En el modo de restablecimiento predeterminado, el cliente intenta recuperar los cambios no sincronizados antes de reiniciar.

Utilizando la estrategia de recopilación de socios

Una colección asociada contiene los mismos datos que la colección original, pero con la nueva definición de esquema vigente. Las colecciones asociadas utilizan activadores de base de datos para garantizar el flujo de datos en ambas direcciones, lo que significa que cuando se escribe en una colección, también se escribe en la otra (con las modificaciones de datos necesarias para el nuevo esquema).

Para implementar un cambio de esquema importante mediante la estrategia de recopilación de socios, consulte Realizar cambios de esquema importantes.