Sync 4.0 Code: Fix for UploadChangesRequestProcesser.GetSyncWriterWithContents()

• 2011年9月12日 上午 12:58

   

   
  

  2

  With the release of the source code for Sync Framework 4.0 I've finally found the cause of a problem I've had since the release of the first private CTP mid last year. The cause of the problem has been related to the normalisation of the tables in my database. So the easiest example is one of 'clients' in my system. Clients can be one of 4 different types, all of which share a large number of common properties but they each have some specific properties that define their type. On normalising this concept you come out with an 'abstract' Client table with the common properties along with 4 'concrete' tables for the different types' specific data. From the Client table perspective the foreign key relationships to each of the 4 specific client tables is a 0..1 relationship. For my own personal sanity I name the foreign key in a table the same name as the primary key of the table it's linking to. So I'm using ClientID in the Client table and then each of the specific client tables has a ClientID to link back. But of course it makes sense that the ClientID in the specific tables is their primary key.

  So with all that background the problem with the UploadChangesRequestProcesser.GetSyncWriterWithContents() method is that in order to determine whether any primary key clashes have occurred it adds a primaryKey string (being the name of the primary key field and its value) as the key to a dictionary. Then it checks future primaryKey strings against that dictionary to determine whether a clash has occurred. That of course falls down when you send a Client entity with ClientID='x' and also send an IndividualClient entity with ClientID='x'. This isn't actually a primary key clash because there is only one ClientID 'x' in the Client table and one ClientID 'x' in the IndividualClient table.

  I'm proposing the following change to the UploadChangesRequestProcesser.GetSyncWriterWithContents() method to handle this class of error in a better way:

          private SyncWriter GetSyncWriterWithContents()
          {
              var conflictEntryKeys = new List<string>();
              var errorEntryKeys = new List<string>();
              var primaryKeyToIncomingEntitiesMapping = new Dictionary<string, IOfflineEntity>();
  
              // Save the mapping between entity PK string -> entity 
              foreach (var entity in _incomingEntities)
              {
                  string primaryKey = ReflectionUtility.GetPrimaryKeyString(entity);
                  string entityType = entity.GetType().ToString();
                  string key = entityType + ":" + primaryKey;
                  if (primaryKeyToIncomingEntitiesMapping.ContainsKey(key))
                  {
                      throw SyncServiceException.CreateInternalServerError(Strings.MultipleEntriesWithSamePrimaryKeyInIncomingRequest);
                  }
  
                  primaryKeyToIncomingEntitiesMapping.Add(key, entity);
              }
  
              if (_rejectedEntities != null)
              {
                  foreach (var entity in _rejectedEntities.Keys)
                  {
                      string primaryKey = ReflectionUtility.GetPrimaryKeyString(entity);
                      string entityType = entity.GetType().ToString();
                      string key = entityType + ":" + primaryKey;
                      if (primaryKeyToIncomingEntitiesMapping.ContainsKey(key))
                      {
                          throw SyncServiceException.CreateInternalServerError(Strings.MultipleEntriesWithSamePrimaryKeyInIncomingRequest);
                      }
  
                      primaryKeyToIncomingEntitiesMapping.Add(key, entity);
                  }
              }
  
  

  
   Fairly simple and the primaryKeyToIncomingEntitiesMapping dictionary isn't used beyond that first checking part of the method so there shouldn't be any adverse effects to the general code base. Obviously you could inline the key creation but I just wanted to make it clearer here.

  • 回覆
  • 引述