Aktualisieren der Metadatenspeicherversion
Die Metadaten-Speicherdienst speichert Replikat- und Elementmetadaten in einer vereinfachten Datenbank. Die Metadaten werden in einem bestimmten Tabellenschema und Binärformat gespeichert, die sich bei der Veröffentlichung neuer Versionen von Sync Framework ändern können. Darüber hinaus können sich Felder benutzerdefinierter Anbieter in der Datenbank ändern, wenn ein Entwickler neue Versionen eines bestimmten Anbieters freigibt. Sync Framework bietet Support für die Aktualisierung des Metadatenspeichers aufgrund von Sync Framework-Versionsänderungen oder Änderungen der Anbieterversion.
Sync Framework bietet auch Support für den Zugriff auf den Metadatenspeicher von Komponenten anderer Versionen, ohne den Metadatenspeicher selbst zu aktualisieren. Weitere Informationen finden Sie unter Zugreifen auf Metadaten von Komponenten anderer Versionen.
Aktualisierung aufgrund einer Änderung der Sync Framework-Version
Das Metadatenspeicherschema und das Dateiformat sind in Sync Framework 2.0 anders als in Sync Framework 1.0. Die Metadaten-Speicherdatei kann entweder im 1.0-Format belassen werden, oder sie kann zur Steigerung der Effizienz auf das 2.0-Format aktualisiert werden.
Hinweis
Das Upgrade der Metadaten-Speicherdatei kann nicht rückgängig gemacht werden. Eine Datei im 2.0-Format kann nicht mehr in das 1.0-Format herabgestuft werden.
Wenn eine Metadaten-Speicherdatei im 1.0-Format von Sync Framework 2.0 geöffnet wird, wird sie automatisch auf das 2.0-Format aktualisiert, außer wenn sich der Anbieter für den Empfang von Upgradebenachrichtigungen registriert und angibt, dass der Metadaten-Speicherdienst das Dateiformat nicht aktualisieren soll. Um die Durchführung von Upgrades zu steuern, führen Sie die folgenden Schritte aus:
Führen Sie vor dem Öffnen der Metadaten-Speicherdatei eine Registrierung für den Empfang des MetadataStoreUpgradeStart-Ereignisses (für verwalteten Code) oder des IMetadataStoreUpgradeCallback-Objekts (für nicht verwalteten Code) durch. Um IMetadataStoreUpgradeCallback zu registrieren, rufen Sie ISyncMetadataStore2::SetMetadataStoreUpgradeNotificationCallback auf.
Öffnen Sie die Metadaten-Speicherdatei mit OpenStore (für verwalteten Code) oder ISqlSyncMetadataStore::OpenStore (für nicht verwalteten Code).
Sync Framework erkennt, dass ein Upgrade benötigt wird, und ruft den MetadataStoreUpgradeStart-Ereignishandler (für verwalteten Code) oder die IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart-Methode (für nicht verwalteten Code) auf.
Der Anbieter gibt mit der SkipUpgrade-Eigenschaft des UpgradeStartEventArgs-Objekts (für verwalteten Code) oder dem pfSkipUpgrade-Parameter der IMetadataStoreUpgradeCallback::OnMetadataStoreFileUpgradeStart-Methode (für nicht verwalteten Code) an, ob die Metadaten-Speicherdatei aktualisiert werden soll.
Aktualisierung aufgrund einer Änderung der Anbieterversion
Ein Anbieter legt mit ProviderVersion (für verwalteten Code) oder IReplicaMetadata2::SetProviderVersion (für nicht verwalteten Code) die Anbieterversion fest, die mit den Metadaten für ein Replikat kompatibel ist. Wenn ein Anbieter einen Metadatenspeicher öffnet, kann dieser mit ProviderVersion (für verwalteten Code) oder IReplicaMetadata2::GetProviderVersion (für nicht verwalteten Code) die Anbieterversion überprüfen, die den Metadaten für ein Replikat zugeordnet ist. Wenn sich die Version des Anbieters, der den Metadatenspeicher öffnet, von der Anbieterversion unterscheidet, die in den Metadaten gespeichert wurde, kann der Anbieter das Metadatenschema für das Replikat aktualisieren. Führen Sie zur Aktualisierung des Metadatenschemas die folgenden Schritte aus:
Starten Sie eine Transaktion, indem Sie BeginTransaction (für verwalteten Code) oder ISyncMetadataStore::BeginTransaction (für nicht verwalteten Code) aufrufen.
Serialisieren Sie die Metadaten für das Replikat mit SyncMetadataStoreSerializer (für verwalteten Code) oder ISyncMetadataStoreSerializer::SerializeReplicaMetadata (für nicht verwalteten Code) in das kanonische Format.
Entfernen Sie die Metadaten für das Replikat aus der Metadaten-Speicherdatei mit RemoveReplicaMetadata (für verwalteten Code) oder ISyncMetadataStore2::RemoveReplicaMetadata (für nicht verwalteten Code).
Initialisieren Sie die Metadaten für das Replikat in der Metadaten-Speicherdatei mit InitializeReplicaMetadata (für verwalteten Code) oder ISyncMetadataStore::InitializeReplicaMetadata (für nicht verwalteten Code). Geben Sie in diesem Aufruf die benutzerdefinierten Spalten und Indizes vom aktualisierten Metadatenschema an.
Importieren Sie die Metadaten, die in Schritt 1 mit DeserializeReplicaMetadata (für verwalteten Code) oder ISyncMetadataStoreSerializer::DeserializeReplicaMetadata (für nicht verwalteten Code) serialisiert wurden. Geben Sie in diesem Aufruf die aktualisierte Anbieterversion an, und stellen Sie ein IProviderUpgradeCallback-Objekt (für verwalteten Code) oder ein IProviderMetadataUpgradeCallback-Objekt (für nicht verwalteten Code) bereit, das Benachrichtigungen von bei der Aktualisierung aufgetretenen Ereignissen empfängt.
Während des Upgrades wird OnCustomReplicaMetadataDeserialized (für verwalteten Code) oder IProviderMetadataUpgradeCallback::OnReplicaCustomFieldDeserialized (für nicht verwalteten Code) aufgerufen, um dem Anbieter das Durchführen von Änderungen am benutzerdefinierten Metadatenfeld des Replikats zu ermöglichen.
Während der Aktualisierung wird für jedes Element einmal OnItemMetadataDeserialized (für verwalteten Code) oder IProviderMetadataUpgradeCallback::OnItemMetadataDeserialized (für nicht verwalteten Code) aufgerufen, um dem Anbieter das Durchführen von Änderungen an den Metadaten für ein Element zu ermöglichen.
Legen Sie die aktualisierte Anbieterversion in den Metadaten für das Replikat mit ProviderVersion (für verwalteten Code) oder IReplicaMetadata2::SetProviderVersion (für nicht verwalteten Code) fest.
Führen Sie einen Commit für die Transaktion aus, indem Sie CommitTransaction (für verwalteten Code) oder ISyncMetadataStore::CommitTransaction (für nicht verwalteten Code) aufrufen.
Überlegungen zur Metadatenkompatibilität
Wenn Sie eine neue Version eines Anbieters freigeben, sollten Sie im Hinblick auf die Metadatenkompatibilität Folgendes beachten:
Formate für Replikat-IDs, Element-IDs usw. (die in SyncIdFormatGroup für verwalteten Code oder in ID_PARAMETERS-Struktur für nicht verwalteten Code angegeben werden) müssen über alle Instanzen und Versionen eines Anbieters innerhalb einer bestimmten Synchronisierungscommunity hinweg identisch sein. Dies ist eine allgemeine Regel, die der Vollständigkeit halber hier erneut erwähnt wird.
Das benutzerdefinierte Feld eines Replikats kann nicht auf eine inkompatible Weise geändert werden. Bei diesem Feld handelt es sich um ein BLOB, das ohne Eingriff von Sync Framework serialisiert und deserialisiert wird. Ändern Sie die Struktur des Felds so, dass eine frühere Anbieterversion nicht in das Feld schreiben oder daraus lesen kann.
Die benutzerdefinierte Spalte und das Indexschema eines Anbieters können zwischen Anbieterversionen wechseln. Diese Schemas können optional in der InitializeReplicaMetadata-Methode (für verwalteten Code) oder der ISyncMetadataStore::InitializeReplicaMetadata-Methode (für nicht verwalteten Code) angegeben werden. Dabei ist jedoch Folgendes zu beachten:
Der Anbieter kann keine inkompatiblen Änderungen am Metadatenschema vornehmen. Sie können z. B. kein benutzerdefiniertes Feld entfernen, dessen Aktualisierung ein vorheriger Anbieter für jede Elementaktualisierung angefordert hat.
Eine neue Version eines Anbieters kann nur dann benutzerdefinierte Spalten hinzufügen, wenn die Aktualisierung dieser Spalten optional ist. Die frühere Version des Anbieters erkennt das Vorhandensein dieser Spalten nicht.
Benutzerdefinierte Spaltennamen und Werte werden serialisiert, Datentypen für diese Spalten, Indizes und andere Schemainformationen jedoch nicht. Dies bedeutet, dass benutzerdefinierte Spalten und Indizes im Metadatenspeicher vor dem Importieren von Metadaten aus einer kanonischen Datei vorhanden sein müssen.
Spaltendatentypen können in einer neueren Version eines Anbieters nicht geändert werden. Dies könnte zu Deserialisierungsfehlern in früheren Versionen eines Anbieters führen.