Mise à niveau de la version de magasin des métadonnées
Le service de stockage des métadonnées stocke les métadonnées de réplica et d'élément dans une base de données légère. Les métadonnées sont stockées dans un schéma de table et un format binaire spécifiques qui peuvent changer avec la publication de nouvelles versions de Sync Framework. En outre, les champs de fournisseurs personnalisés dans la base de données peuvent changer dans le cas où un développeur publie de nouvelles versions d'un fournisseur particulier. Sync Framework fournit la prise en charge de la mise à niveau du magasin des métadonnées lorsque les versions de Sync Framework et du fournisseur changent.
Sync Framework fournit également la prise en charge de l'accès au magasin des métadonnées à partir de composants de versions différentes sans mettre à niveau le magasin des métadonnées lui-même. Pour plus d'informations, consultez Accès aux métadonnées à partir de composants de versions différentes.
Mise à niveau due au changement de version de Sync Framework
Le schéma et le format de fichier du magasin des métadonnées sont différents dans Sync Framework 2.1 et 2.0 par rapport à Sync Framework 1.0. Le fichier de magasin des métadonnées peut être conservé au format 1.0 ou, pour une meilleure efficacité, il peut être mis à niveau au nouveau format.
Notes
La mise à niveau du fichier de magasin des métadonnées ne peut pas être annulée. Un fichier au nouveau format ne peut pas revenir au format 1.0.
Lorsqu'un fichier de magasin des métadonnées au format 1.0 est ouvert avec Sync Framework 2.1 ou 2.0, il est automatiquement mis à niveau au nouveau format, à moins que le fournisseur ne soit inscrit pour recevoir une notification de la mise à niveau et n'indique que le service de stockage des métadonnées ne doit pas mettre à niveau le format de fichier. Pour contrôler si la mise à niveau a lieu, effectuez les étapes suivantes.
Avant d'ouvrir le fichier de magasin des métadonnées, inscrivez-vous pour recevoir l'événement MetadataStoreUpgradeStart (pour le code managé) ou inscrivez un objet IMetadataStoreUpgradeCallback (pour le code non managé). Pour enregistrer l'objet IMetadataStoreUpgradeCallback, appelez ISyncMetadataStore2::SetMetadataStoreUpgradeNotificationCallback.
Ouvrez le fichier de magasin des métadonnées à l'aide de OpenStore (pour le code managé) ou ISqlSyncMetadataStore::OpenStore (pour le code non managé).
Sync Framework détecte qu'une mise à niveau est exigée, et appelle le gestionnaire d'événements MetadataStoreUpgradeStart (pour le code managé) ou la méthode IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart (pour le code non managé).
Le fournisseur indique si le fichier de magasin des métadonnées doit être mis à niveau, en utilisant la propriété SkipUpgrade de l'objet UpgradeStartEventArgs (pour le code managé) ou le paramètre pfSkipUpgrade de la méthode IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart (pour le code non managé).
Mise à niveau due au changement de version du fournisseur
Un fournisseur définit la version de fournisseur qui est compatible avec les métadonnées pour un réplica à l'aide de ProviderVersion (pour le code managé) ou IReplicaMetadata2::SetProviderVersion (pour le code non managé). Lorsqu'un fournisseur ouvre un magasin des métadonnées, il peut vérifier la version de fournisseur associée aux métadonnées pour un réplica à l'aide de ProviderVersion (pour le code managé) ou IReplicaMetadata2::GetProviderVersion (pour le code non managé). Lorsque la version du fournisseur qui ouvre le magasin des métadonnées est différente de celle qui est stockée dans les métadonnées, le fournisseur peut mettre à niveau le schéma de métadonnées pour le réplica. Pour mettre à niveau le schéma de métadonnées, effectuez les étapes suivantes.
Démarrez une transaction en appelant BeginTransaction (pour le code managé) ou ISyncMetadataStore::BeginTransaction (pour le code non managé).
Sérialisez les métadonnées pour le réplica au format canonique à l'aide de SyncMetadataStoreSerializer (pour le code managé) ou ISyncMetadataStoreSerializer::SerializeReplicaMetadata (pour le code non managé).
Supprimez les métadonnées pour le réplica du magasin des métadonnées en utilisant RemoveReplicaMetadata (pour le code managé) ou ISyncMetadataStore2::RemoveReplicaMetadata (pour le code non managé).
Initialisez les nouvelles métadonnées pour le réplica dans le magasin des métadonnées en utilisant InitializeReplicaMetadata (pour le code managé) ou ISyncMetadataStore::InitializeReplicaMetadata (pour le code non managé). Dans cet appel, spécifiez les colonnes et les index personnalisés du schéma de métadonnées mis à niveau.
Importez les métadonnées sérialisées dans l'étape 1 à l'aide de DeserializeReplicaMetadata (pour le code managé) ou ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (pour le code non managé). Spécifiez la version de fournisseur mise à niveau dans cet appel et fournissez un objet IProviderUpgradeCallback (pour le code managé) ou IProviderMetadataUpgradeCallback (pour le code non managé) qui recevra une notification des événements qui se produisent pendant la mise à niveau.
Pendant la mise à niveau, OnCustomReplicaMetadataDeserialized (pour le code managé) ou IProviderMetadataUpgradeCallback::OnReplicaCustomFieldDeserialized (pour le code non managé) est appelé pour permettre au fournisseur d'apporter des modifications au champ de métadonnées personnalisé du réplica.
Pendant la mise à niveau, OnItemMetadataDeserialized (pour le code managé) ou IProviderMetadataUpgradeCallback::OnItemMetadataDeserialized (pour le code non managé) est appelé une fois par élément désérialisé, afin de permettre au fournisseur d'apporter des modifications aux métadonnées pour un élément.
Définissez la version de fournisseur mise à niveau dans les métadonnées pour le réplica à l'aide de ProviderVersion (pour le code managé) ou IReplicaMetadata2::SetProviderVersion (pour le code non managé).
Validez la transaction en appelant CommitTransaction (pour le code managé) ou ISyncMetadataStore::CommitTransaction (pour le code non managé).
Considérations sur la compatibilité des métadonnées
Lorsque vous diffusez une nouvelle version d'un fournisseur, vous devez être informé des considérations suivantes qui sont en rapport avec la compatibilité de métadonnées :
Les formats pour les ID de réplica, ID d'élément, etc (spécifiés dans SyncIdFormatGroup (pour le code managé) Structure ID_PARAMETERS (pour le code non managé) doivent être les mêmes dans toutes les instances et versions d'un fournisseur dans une communauté de synchronisation particulière. Il s'agit d'une règle générale, mais elle est réitérée ici par souci d'exhaustivité.
Le champ personnalisé d'un réplica ne peut pas changer d'une manière incompatible. Ce champ est un objet BLOB qui est sérialisé et désérialisé sans l'intervention de Sync Framework. Ne modifiez pas la structure du champ d'une façon qui empêche une version de fournisseur antérieure de lire le champ ou d'y écrire.
Une colonne personnalisée et un schéma d'index d'un fournisseur peuvent changer en fonction des versions de fournisseur. Ces schémas sont éventuellement spécifiés dans la méthode InitializeReplicaMetadata (pour le code managé) ou la méthode ISyncMetadataStore::InitializeReplicaMetadata (pour le code non managé). Toutefois, gardez à l'esprit ce qui suit :
Le fournisseur ne peut pas apporter de modifications incompatibles au schéma de métadonnées. Par exemple, vous ne pouvez pas supprimer un champ personnalisé qu'un fournisseur précédent exigeait de mettre à jour pour chaque mise à jour d'élément.
Une nouvelle version d'un fournisseur peut ajouter des colonnes personnalisées uniquement si la mise à jour de ces colonnes est facultative. La version précédente du fournisseur n'aura pas connaissance de l'existence de ces colonnes.
Les noms et valeurs de colonnes personnalisées sont sérialisés, mais les types de données pour ces colonnes, index et autres informations de schéma ne le sont pas. Cela signifie que les colonnes et index personnalisés doivent exister dans le magasin des métadonnées avant d'importer des métadonnées à partir d'un fichier canonique.
Les types de données de colonnes ne peuvent pas être modifiés dans une version plus récente d'un fournisseur. Cela pourrait provoquer des erreurs de désérialisation pour les versions précédentes d'un fournisseur.