Métadonnées requises pour les fournisseurs standard

Article
08/18/2010

Sync Framework requiert un jeu particulier de métadonnées pour chaque réplica et pour chaque élément qui sera synchronisé.

Métadonnées requises pour chaque réplica

Chaque réplica est requis pour stocker le jeu de métadonnées affiché dans le tableau suivant.

Élément de métadonnées	Description
ID de réplica	Est l'identificateur unique d'un réplica dans une communauté de synchronisation. Bien que l'ID de réplica soit un ID flexible et, par conséquent, peut être défini par le schéma pour la communauté, nous recommandons un GUID de 16 octets. Le format d'un ID de réplica qui est passé à une méthode Sync Framework doit correspondre au format spécifié par le fournisseur. Code managé Le format est spécifié par la propriété ReplicaIdFormat de la classe SyncIdFormatGroup. L'ID est représenté par la classe SyncId. Code non managé Le format est spécifié par le champ replicaId de la structure Structure ID_PARAMETERS. L'ID est représenté par la structure SYNC_ID.
Nombre de cycles actuel	Est le nombre de cycles actuel pour le réplica. Il s'agit d'un nombre conceptuel qui peut être inféré à partir de la dernière version locale dans la connaissance par élément ou par une valeur qui augmente de façon monotone qui est disponible au réplica. Par exemple, un réplica peut utiliser l'heure d'horloge actuelle si elle empêche la réinitialisation de cette valeur. Code managé Représenté par UInt64. Code non managé Représenté par ULONGLONG.
Mappage de clés de réplicas	Représente un mappage entre les ID de réplica et les clés sur 4 octets. Dans la mesure où les occurrences d'ID de réplica sont répétées dans les métadonnées (GUID 16 octets recommandés), il est plus efficace de représenter les ID en utilisant une table pour mapper les ID de réplica sur des clés sur 4 octets. Ces clés sont ensuite utilisées là où les références à des réplicas particuliers sont requises. Code managé Représenté en utilisant ReplicaKeyMap. Code non managé Représenté en utilisant IReplicaKeyMap.
Connaissance actuelle	Correspond au résumé des informations de versions que le réplica connaît pour l'étendue spécifiée. La connaissance de réplica est manipulée via les services de métadonnées et ne doit pas être manipulée directement. Code managé Représenté en utilisant SyncKnowledge. Code non managé Représenté en utilisant ISyncKnowledge.
Connaissance oubliée	Active un réplica qui détecte qu'un réplica partenaire n'a pas connaissance des éléments qui ont été supprimés. Cela se produit lorsque des objets tombstone pour ces éléments ont été nettoyés. La connaissance oubliée est manipulée via les services de métadonnées. Code managé Représenté en utilisant ForgottenKnowledge. Code non managé Représenté en utilisant IForgottenKnowledge.
Journal des conflits	Est un journal des conflits qui se produit lorsque des conflits ont été supprimés après l'énumération des modifications qui n'ont pas été résolues. Les réplicas sont requis pour maintenir un journal des conflits uniquement si des conflits sont enregistrés pendant la synchronisation. La représentation d'un journal des conflits est déterminée par le réplica et l'accès à ce journal n'a pas besoin d'être fourni pour Sync Framework. Toutefois, lorsqu'un applicateur de modifications est utilisé, Sync Framework peut aider à maintenir un journal des conflits. Pour plus d'informations, consultez Journalisation et gestion des conflits.
Journal tombstone	Stocke les informations relatives à la suppression d'éléments d'un réplica, afin que les modifications de suppression soient correctement propagées dans les communautés de synchronisation et que les éléments supprimés ne soient pas réintroduits par erreur. Les réplicas sont requis pour maintenir un journal tombstone. La représentation d'un journal tombstone est déterminée par le réplica et l'accès à ce journal n'a pas besoin d'être fourni à Sync Framework. Pour plus d'informations, consultez Gestion d'objets tombstone.

Métadonnées requises pour chaque élément

Chaque élément qui doit être synchronisé doit disposer du jeu de métadonnées indiqué dans le tableau suivant.

Élément de métadonnées	Description
ID global	Est un identificateur pour un élément stocké dans un réplica. Dans la mesure où le réplica est responsable de la génération des ID globaux, le réplica peut allouer des ID globaux qui rendent l'énumération plus efficace. Par exemple, une communauté peut définir son format d'ID global afin qu'il s'agisse d'un GUID précédé par un préfixe de 8 octets. Le préfixe peut ensuite être utilisé pour contrôler l'ordre de tri des ID globaux. Cela permet aux fournisseurs d'utiliser plus facilement des plages pour énumérer les modifications, et dans la mesure où une plage peut contenir un grand nombre d'éléments, la structure de la connaissance peut être plus compacte lorsque des éléments sont représentés sous forme de groupes classés. Pour plus d'informations sur les formats d'ID globaux, consultez ID flexibles. Code managé Le format est spécifié par la propriété ItemIdFormat de la classe SyncIdFormatGroup. L'ID est représenté par la classe SyncId. Code non managé Le format est spécifié par le champ itemId de la structure Structure ID_PARAMETERS. L'ID est représenté par la structure SYNC_ID.
Version actuelle	Est la version mise à jour la plus récente pour un élément particulier. La version actuelle contient la clé du réplica qui a mis à jour l'élément en dernier et le nombre de cycles de réplica lorsque la modification a eu lieu. Cette version est stockée par unité de modification lorsqu'un élément utilise des unités de modification. Par exemple, un contact peut avoir des numéros de version d'unité de modification distincts pour les champs adresse et numéro de téléphone. Code managé Représenté par SyncVersion. Code non managé Représenté par SYNC_VERSION.
Version de création	Est la version lors de la création de l'élément. La version de création contient la clé du réplica qui a créé l'élément, ainsi que le nombre de cycles de ce réplica lorsque l'élément a été créé. Code managé Représenté par SyncVersion. Code non managé Représenté par SYNC_VERSION.

ID global

Est un identificateur pour un élément stocké dans un réplica. Dans la mesure où le réplica est responsable de la génération des ID globaux, le réplica peut allouer des ID globaux qui rendent l'énumération plus efficace. Par exemple, une communauté peut définir son format d'ID global afin qu'il s'agisse d'un GUID précédé par un préfixe de 8 octets. Le préfixe peut ensuite être utilisé pour contrôler l'ordre de tri des ID globaux. Cela permet aux fournisseurs d'utiliser plus facilement des plages pour énumérer les modifications, et dans la mesure où une plage peut contenir un grand nombre d'éléments, la structure de la connaissance peut être plus compacte lorsque des éléments sont représentés sous forme de groupes classés. Pour plus d'informations sur les formats d'ID globaux, consultez ID flexibles.

Code managé Le format est spécifié par la propriété ItemIdFormat de la classe SyncIdFormatGroup. L'ID est représenté par la classe SyncId.

Code non managé Le format est spécifié par le champ itemId de la structure Structure ID_PARAMETERS. L'ID est représenté par la structure SYNC_ID.

Version actuelle

Est la version mise à jour la plus récente pour un élément particulier. La version actuelle contient la clé du réplica qui a mis à jour l'élément en dernier et le nombre de cycles de réplica lorsque la modification a eu lieu.

Cette version est stockée par unité de modification lorsqu'un élément utilise des unités de modification. Par exemple, un contact peut avoir des numéros de version d'unité de modification distincts pour les champs adresse et numéro de téléphone.

Code managé Représenté par SyncVersion.

Code non managé Représenté par SYNC_VERSION.

Version de création

Est la version lors de la création de l'élément. La version de création contient la clé du réplica qui a créé l'élément, ainsi que le nombre de cycles de ce réplica lorsque l'élément a été créé.

Code managé Représenté par SyncVersion.

Code non managé Représenté par SYNC_VERSION.

Capacité de stockage nécessaire

Dans la mesure où le réplica détermine le format pour l'ID global, la quantité d'espace requise pour stocker les métadonnées pour chaque élément varie. Toutefois, lorsque le format recommandé d'un GUID plus un préfixe de 8 octets est utilisé, la quantité totale de stockage requise est de 48 octets, comme indiqué dans le tableau suivant.

Élément	Octets
ID global	24 (GUID + préfixe de 8 octets)
Version actuelle	12 (clé de réplica de 4 octets + nombre de cycles de 8 octets)
Version de création	12 (clé de réplica de 4 octets + nombre de cycles de 8 octets)
	48 octets au total

Métadonnées pour les conflits de contraintes

Lorsque des conflits de contraintes sont résolus en fusionnant les deux éléments en conflit, des métadonnées supplémentaires sont requises pour les éléments fusionnés. Pour plus d'informations, consultez Détection et résolution des conflits de contraintes.

Métadonnées pour les filtres personnalisés

Lorsque des filtres personnalisés sont utilisés, des métadonnées supplémentaires sont requises pour chaque réplica et chaque élément. Pour plus d'informations, consultez Filtrage des données de synchronisation.