Actualiza tu 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.

A non-breaking change is a change that you can make in your server-side schema or your object model without requiring additional handling in your app. Also known as additive changes, they apply automatically to synced realms.

Nota

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

When you only make non-breaking changes to the server-side schema, no additional action is required. However, if you then try to apply these changes to your client object model, you may need to perform a migration. If the client device has an existing realm file, you must perform a migration. For details, see the Modify an Object Schema page in your preferred SDK.

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
Adicionar um tipo de objeto Realm	Irrompible	Irrompible
Agregar un valor predeterminado a una propiedad	Irrompible	Irrompible
Agregar una propiedad requerida	Irrompible	Irrompible
Add an optional property	Irrompible	Irrompible
Eliminar un tipo de objeto	Noticia de última hora	Irrompible
Eliminar una propiedad opcional u obligatoria	Noticia de última hora	Irrompible
Change an object type name	Rotura*	Rotura*
Cambiar el nombre de una propiedad	Rotura*	Rotura*
Cambiar el tipo de propiedad pero conservar el nombre	Noticia de última hora	Noticia de última hora
Change property's status between optional and required	Noticia de última hora	Noticia de última hora

Tip

Rename a property

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 Realm

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.

If you want to add an object type to both the server-side schema and the client object model, you can add the object type to the object model, and use Development Mode to let App Services handle the server-side schema updates. Or you can manually add the object type to both the model and the schema.

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.

Add a Required Property

You can add a required property to the client's object model, and use Development Mode to let App Services infer the server-side schema updates. Or you can manually add the required property to both the client model and the Atlas schema. However, you should consider making the property optional to avoid the need to modify existing Atlas documents.

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

You can remove an object from the client's object model as a non-breaking change. If you remove the object from the server-side schema, it is a breaking change. For this reason, we recommend you remove the object type from the client-side object model only and leave it in place on the server-side schema.

Remove a Property

Puedes remover una propiedad opcional o requerida del Modelo de objeto del lado del cliente y dejarla en su lugar en el esquema del lado del servidor. Este es un cambio no disruptivo del modelo de objetos.

Si se remueve una propiedad del esquema del lado del servidor, se considera un cambio disruptivo. Por esta razón, recomendamos que se remueva la propiedad únicamente del Modelo de objeto del lado del cliente y que permanezca en el esquema del lado 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

Changing an object's name on both the server-side schema and the client-side object model is a breaking change. However, some SDKs offer an API to map a new object name to an existing name in the schema. This allows you to rename an object on the client but not change the object name on the server. In this way, you avoid triggering a migration. Object name mapping is supported in the following SDKs:

• Kotlin

• Java

• .NET

• Flutter

If name mapping is not an option, consider implementing a partner collection strategy, in which you keep the existing collection and schema, and create a new collection with the new schema.

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: Remap a Property

• Java: Rename a Field

• Kotlin: Remapear una propiedad

• .NET: Cambiar el nombre de una propiedad

• Node.js: Remap a Property

• React Native: Reasignar una propiedad

• Swift: Reasignar una propiedad

If name mapping is not an option, consider implementing a partner collection strategy, in which you keep the existing collection and schema, and create a new collection with the new schema.

Si eliges cambiar el nombre de la propiedad en lugar de utilizar la estrategia de colección de socios, debes terminar la sincronización, actualizar manualmente el esquema y volver a habilitar la sincronización. Además, tu aplicación cliente debe realizar un restablecimiento del cliente para restaurar sincronizar. En el modo de restablecimiento del cliente por defecto, el cliente intenta recuperar cualquier cambio no sincronizado antes de restablecer.

Al terminar y volver a habilitar la sincronización, también debes actualizar los documentos existentes de Atlas para que puedan sincronizarse con tus aplicaciones clientes. Sin este manejo adicional, esos documentos no se sincronizan y podría parecer en el cliente que los datos se han perdido. Podrías resolver este problema de dos maneras:

• Cambia el antiguo nombre de campo 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.

After you've made these changes, the appropriate documents sync to the client application.

Cambiar un tipo de propiedad pero conservar el nombre

Cambiar el tipo de propiedad es un cambio disruptivo, tanto en el esquema del lado del servidor como en el Modelo de objeto lado del cliente.

En lugar de cambiar el tipo de una propiedad, considera implementar la estrategia de colección de emparejamiento, en la que se conserva la colección y el esquema existentes y se crea una nueva colección con el nuevo esquema.

If you choose to change the property's type instead of using the partner collection strategy, you must terminate sync, manually update the schema, and re-enable sync. In addition, your client application must perform a client reset to restore Sync. In the default client reset mode, the client attempts to recover any unsynced changes before resetting.

Al terminar y volver a habilitar la sincronización, también debes actualizar los documentos existentes de Atlas para que puedan sincronizarse con tus aplicaciones clientes. Sin este manejo adicional, esos documentos no se sincronizan y podría parecer en el cliente que los datos se han perdido. Podrías resolver este problema de dos maneras:

• Change the old field type on each document to match the new schema

• 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.

After you've made these changes, the appropriate documents should once again sync to the client application.

Cambia el estado de una propiedad entre Opcional y Requerido

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.

Using the Partner Collection Strategy

Una colección asociada es una colección que contiene los mismos datos que la colección original, pero tiene la nueva definición de esquema implementada. Las colecciones asociadas utilizan activadores de base de datos para garantizar que los datos fluyan en ambas direcciones, lo que significa que cuando se escribe en una colección, también se escribe en la otra (con las modificaciones 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.