Actualizar la versión del almacén de metadatos
Metadata Storage Service almacena metadatos de réplica y del elemento en una base de datos ligera. Los metadatos se almacenan en un esquema de tabla específico y en formato binario que podrían verse modificados según vayan saliendo versiones nuevas de Sync Framework. Además, los campos de proveedor personalizado de la base de datos podrían cambiar si un desarrollador publica nuevas versiones de un determinado proveedor. Sync Framework proporciona compatibilidad para actualizar el almacén de metadatos si la versión de Sync Framework y del proveedor cambia.
Sync Framework también proporciona compatibilidad para obtener acceso al almacén de metadatos desde componentes con versiones diferentes sin necesidad de actualizar el propio almacén de metadatos. Para obtener más información, vea Obtener acceso a los metadatos desde componentes con versiones diferentes.
Realizar la actualización porque la versión de Sync Framework ha cambiado
El esquema del almacén de metadatos y el formato de archivo son diferentes en Sync Framework 2.0 y en Sync Framework 1.0. El archivo de almacén de metadatos se puede mantener en el formato de la versión 1.0 o, para obtener una eficacia mayor, se puede actualizar al formato 2.0.
Nota
La actualización del archivo de almacén de metadatos no se puede deshacer. Un archivo con el formato 2.0 no se puede revertir al formato 1.0.
Cuando Sync Framework 2.0 abre un archivo de almacén de metadatos en el formato 1.0, se actualiza automáticamente al formato 2.0, a menos que el proveedor se registre para recibir una notificación de la actualización e indique que Metadata Storage Service no debería actualizar el formato de archivo. Para controlar si la actualización se lleva a cabo, realice los pasos siguientes.
Antes de abrir el archivo de almacén de metadatos, regístrese para recibir el evento MetadataStoreUpgradeStart (en código administrado) o registre un objeto IMetadataStoreUpgradeCallback (en código no administrado). Para registrar el objeto IMetadataStoreUpgradeCallback, llame a ISyncMetadataStore2::SetMetadataStoreUpgradeNotificationCallback.
Abra el archivo de almacén de metadatos utilizando OpenStore (en código administrado) o ISqlSyncMetadataStore::OpenStore (en código no administrado).
Sync Framework detecta que se necesita una actualización y llama al controlador de eventos MetadataStoreUpgradeStart (en código administrado) o al método IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart (en código no administrado).
El proveedor indica si se debería actualizar el archivo de almacén de metadatos a través de la propiedad SkipUpgrade del objeto UpgradeStartEventArgs (en código administrado) o del parámetro pfSkipUpgrade del método IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart (en código no administrado).
Realizar la actualización porque la versión del proveedor ha cambiado
Un proveedor establece la versión del proveedor que es compatible con los metadatos de una réplica utilizando ProviderVersion (en código administrado) o IReplicaMetadata2::SetProviderVersion (en código no administrado). Cuando un proveedor abre un almacén de metadatos, puede comprobar la versión del proveedor que está asociada a los metadatos de una réplica utilizando ProviderVersion (en código administrado) o IReplicaMetadata2::GetProviderVersion (en código no administrado). Cuando la versión del proveedor que abre el almacén de metadatos es diferente de la versión del proveedor que está almacenada en los metadatos, el proveedor puede actualizar el esquema de metadatos de la réplica. Para actualizar el esquema de metadatos, realice los pasos siguientes.
Inicie una transacción llamando a BeginTransaction (en código administrado) o ISyncMetadataStore::BeginTransaction (en código no administrado).
Serialice los metadatos de la réplica con el formato canónico utilizando SyncMetadataStoreSerializer (en código administrado) o ISyncMetadataStoreSerializer::SerializeReplicaMetadata (en código no administrado).
Quite los metadatos de la réplica del almacén de metadatos utilizando RemoveReplicaMetadata (en código administrado) o ISyncMetadataStore2::RemoveReplicaMetadata (en código no administrado).
Inicialice nuevos metadatos de la réplica en el almacén de metadatos utilizando InitializeReplicaMetadata (en código administrado) o ISyncMetadataStore::InitializeReplicaMetadata (en código no administrado). En esta llamada, especifique las columnas personalizadas y los índices del esquema de metadatos actualizado.
Importe los metadatos serializados en el paso 1 utilizando DeserializeReplicaMetadata (en código administrado) o ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (en código no administrado). Especifique la versión del proveedor actualizado en esta llamada y proporcione un objeto IProviderUpgradeCallback (en código administrado) o IProviderMetadataUpgradeCallback (en código no administrado) que recibirá la notificación de los eventos que se producen durante la actualización.
Durante la actualización, se llama a OnCustomReplicaMetadataDeserialized (en código administrado) o a IProviderMetadataUpgradeCallback::OnReplicaCustomFieldDeserialized (en código no administrado) para permitir que el proveedor realice cambios en el campo de metadatos personalizado de la réplica.
Durante la actualización, se llama a OnItemMetadataDeserialized (en código administrado) o IProviderMetadataUpgradeCallback::OnItemMetadataDeserialized (en código no administrado) una vez por cada elemento que se deserializa con el fin de permitir al proveedor realizar cualquier cambio en los metadatos de un elemento.
Establezca la versión del proveedor actualizado en los metadatos de la réplica utilizando ProviderVersion (en código administrado) o IReplicaMetadata2::SetProviderVersion (en código no administrado).
Confirme la transacción llamando a CommitTransaction (en código administrado) o ISyncMetadataStore::CommitTransaction (en código no administrado).
Consideraciones sobre la compatibilidad de los metadatos
Cuando se publica una nueva versión de un proveedor, debe tener en cuenta las consideraciones siguientes relativas a la compatibilidad de los metadatos:
Los formatos de los identificadores de réplicas, identificadores de elementos, etc., que se especifican en SyncIdFormatGroup (en código administrado) o Estructura ID_PARAMETERS (en código no administrado), deben ser los mismos en todas las instancias y versiones de un proveedor de una determinada comunidad de sincronización. Aunque se trata de una regla general, conviene reiterarla aquí para disponer de toda la información.
El campo personalizado de una réplica no se puede cambiar de un modo que sea incompatible. Este campo es un BLOB que se serializa y deserializa sin la intervención de Sync Framework. No cambie la estructura del campo de forma que impida que un proveedor de una versión anterior realice operaciones de lectura o escritura en el campo.
El esquema de índices y columnas personalizadas de un proveedor puede variar entre sus versiones. Estos esquemas pueden especificarse opcionalmente en el método InitializeReplicaMetadata (en código administrado) o en el método ISyncMetadataStore::InitializeReplicaMetadata (en código no administrado). Sin embargo, conviene tener en cuenta lo siguiente:
El proveedor no puede realizar cambios que sean incompatibles en el esquema de metadatos. Por ejemplo, no puede quitar un campo personalizado que un proveedor anterior necesitara actualizar en cada actualización de los elementos.
Una nueva versión de un proveedor solamente puede agregar columnas personalizadas si la actualización de estas columnas es opcional. La versión anterior del proveedor no tendrá constancia de que estas columnas existen.
Los nombres y valores de columnas personalizadas se serializan, pero los tipos de datos de estas columnas, los índices y otra información del esquema, no. Esto significa que los índices y las columnas personalizadas deben estar en el almacén de metadatos antes de importar los metadatos de un archivo canónico.
Los tipos de datos de columna no se pueden cambiar en una versión más reciente de un proveedor. Esto podría producir errores de deserialización en las versiones anteriores de un proveedor.