none
Map local item key to replica item key RRS feed

  • Question

  • I have two simple providers and use SqlMetaDataStore. When syncing, I inform Sync Framework about keys and versions (through ItemFieldDictionary). Can I get this information back after sync and if yes how?

    I  can enumerate live items on each provider's metadata using SimpleSyncServices, but I can't find out how to correspond the entries.

    Wednesday, March 30, 2011 12:50 AM

Answers

  • Simple Provider (Full enuermation) Framework is a Framework that helps to cover Sync Metadata related operations and allow the sync developer to focus on the data operations. For the simplicity with that framework, you only have access the data part (including key, which is part of the data and including other data). Normally, the association of source data and dest data is with some natural association, for example, both sides have same file name etc. It's possible and supported to give same source and dest item different key names (file names in this case) but the association for these same items has to be maintained by the sync application in certain way, such as a database table with the mapping information.

    It's also possible to dig into one Metadata store, with Metadata store API, search the key (file name in this case) and return a global item id, then use it to search in the other metadata store and find out the key on that side. However, if this is important then instead of using Simple Provider Framework, you may consider using Metadata Store to build a Knowledge Sync Provider.

    Thursday, March 31, 2011 5:16 PM
    Answerer
  • Thanks, with your help I was able to figure it out ;) Yes, searching key in the source metadata, extracting the ID and searching this ID in the target metadata was what I looking for, but without your confirmation that it can be done I just could not figure out the way. Here is what I did in case somebody tries to repeat my steps (it still feels like a hack):

    1. Extracted the ReplicaMetadata with localProvider.GetMetadataStore(...).GetSingleReplicaMetadata().
    2. Opened the metadata file with Server Explorer and looked into SyncItemMetadata_XXXX.. table. I found that my source keys are residing within CustomField1_6.
    3. I called localReplicaMetadata.FindItemMetadataByIndexedField("CustomField1_6", mykey) and it found the item metadata! (to my surprize)
    4. remoteProvider.GetMetaDataStore(...).GetSingleReplicaMetadata().FindItemMetadataByID(localItemMetadata.GlobalId) found the remote item metadata.
    5. remoteItemMetadata.GetStrField("CustomField1_6") returned the correct remote key.

    Now, after all this I have a few questions which I would probably would not have if your documentation didn't suck so much:

    1. The first thing I did was to call GetSingleReplicaMetadata(). There is also GetReplicaMetadata method which takes a replica id parameter. Do I understand it correctly that GetSingleReplicaMetadata() returns the first from all populated replica metedatas?
    2. What does "6" in "CustomField1_6" mean? Can it be different? Comment - having one part of API (MetadataSchema) defining Custom Fields using uint id's and another part of API (FindItemMetadataByIndexedField) using string as a field name is just a brilliant architecture ;)
    3. FindItemMetadataByIndexedField returns an enumerator. If my key is consisting from one field, can it ever return more than one entry? (I understand it can if I have a combined key and search by the first part)
    4. Do you guys have plans to publish SimpleProviders source code? Would save us developers some time figuring Sync Framework out.

     

    Thursday, March 31, 2011 11:19 PM

All replies

  • The item key is used to link the data and metadata. The key is designated in Schema for the simple provider and should be meaningful in the data store as well.

    For example, if sync files, filePath can be a key, you can set it in the MetadataSchema of the provider. Then later with the filePath as key, item's metadata can be obtained from metadata store (by the Provider Framework), also, with the filePath, you can load the file itself.

     

    Wednesday, March 30, 2011 7:42 PM
    Answerer
  • My question probably wasn't clear enough. I'll try to wrap it into an example.

    For example, the sync is done by using custom File provider inherited from Simple Provider. Sync direction is Upload. File names are generated randomly by the destination provider.

    After sync, I need to map local file names to corresponding destination file names. What API calls I need to do it?

    Wednesday, March 30, 2011 8:29 PM
  • There is no problem that the source file name and dest file name are different. Internally, the Metadata store holds a global item key. The provider framework uses this to sync these 2 files and consider them same item.

    The dest file name is designated by your implement in InsertItem call, when you get a source file say fileSrc1, you can insert a file on Dest to fileDest1 then return all required properties to the provider framework. Now next time, you change fileSrc1, you will get call to UpdateItem with the key of fileDest1. The mapping is automatically done for you.

    Wednesday, March 30, 2011 9:32 PM
    Answerer
  • Let's get even more concrete - I feel there is still some misunderstanding. For simplicity, let's have a single file in the source directory.

    1. EnumerateChanges is called on source provider. We return "File1.txt" as a key and modification time as keyAndExpectedVersion.

    2. LoadChangeData is called on source provider. We return the file content, which is passed to InsertItem on destination provider. destination provider generates a random file name (f.e. "abcde.txt") and returns this file name with modification time as keyAndExpectedVersion.

    3. Sync has ended, I have access to both metadata storages. I need to extract the pair "File1.txt"-"abcde.txt" from the metadata. Is it possible at all?

    So far I see a possibility to combine the source key with the source data and return the combo from LoadChangeData, and have the destination key consisting from both source file name and destination file name. But this seems kind of inefficient - metadata can correspond both keys when syncing - why I cannot do it post-sync?

    Thursday, March 31, 2011 1:16 AM
  • Simple Provider (Full enuermation) Framework is a Framework that helps to cover Sync Metadata related operations and allow the sync developer to focus on the data operations. For the simplicity with that framework, you only have access the data part (including key, which is part of the data and including other data). Normally, the association of source data and dest data is with some natural association, for example, both sides have same file name etc. It's possible and supported to give same source and dest item different key names (file names in this case) but the association for these same items has to be maintained by the sync application in certain way, such as a database table with the mapping information.

    It's also possible to dig into one Metadata store, with Metadata store API, search the key (file name in this case) and return a global item id, then use it to search in the other metadata store and find out the key on that side. However, if this is important then instead of using Simple Provider Framework, you may consider using Metadata Store to build a Knowledge Sync Provider.

    Thursday, March 31, 2011 5:16 PM
    Answerer
  • Thanks, with your help I was able to figure it out ;) Yes, searching key in the source metadata, extracting the ID and searching this ID in the target metadata was what I looking for, but without your confirmation that it can be done I just could not figure out the way. Here is what I did in case somebody tries to repeat my steps (it still feels like a hack):

    1. Extracted the ReplicaMetadata with localProvider.GetMetadataStore(...).GetSingleReplicaMetadata().
    2. Opened the metadata file with Server Explorer and looked into SyncItemMetadata_XXXX.. table. I found that my source keys are residing within CustomField1_6.
    3. I called localReplicaMetadata.FindItemMetadataByIndexedField("CustomField1_6", mykey) and it found the item metadata! (to my surprize)
    4. remoteProvider.GetMetaDataStore(...).GetSingleReplicaMetadata().FindItemMetadataByID(localItemMetadata.GlobalId) found the remote item metadata.
    5. remoteItemMetadata.GetStrField("CustomField1_6") returned the correct remote key.

    Now, after all this I have a few questions which I would probably would not have if your documentation didn't suck so much:

    1. The first thing I did was to call GetSingleReplicaMetadata(). There is also GetReplicaMetadata method which takes a replica id parameter. Do I understand it correctly that GetSingleReplicaMetadata() returns the first from all populated replica metedatas?
    2. What does "6" in "CustomField1_6" mean? Can it be different? Comment - having one part of API (MetadataSchema) defining Custom Fields using uint id's and another part of API (FindItemMetadataByIndexedField) using string as a field name is just a brilliant architecture ;)
    3. FindItemMetadataByIndexedField returns an enumerator. If my key is consisting from one field, can it ever return more than one entry? (I understand it can if I have a combined key and search by the first part)
    4. Do you guys have plans to publish SimpleProviders source code? Would save us developers some time figuring Sync Framework out.

     

    Thursday, March 31, 2011 11:19 PM
  • For some one of the Qs:

    1. One metadata store may support multi-replicas if needed, normally there is only one.

    2. The column name of CustomField1_6 is used internally by Provider Framework and the framework has metadata to know the column name. Opening the metadata store with Simple provider is not a recommended way, my information is only for a possible approach if really needed but should not be used for genernal purpose.

    3. Indexed field may not be unique, in simple provider, you may use FindByUniqueIndexedField.

     

    Friday, April 1, 2011 5:57 PM
    Answerer