【问题标题】:Azure TableEntity - Hooking to Read / Write OperationsAzure TableEntity - 挂钩读/写操作
【发布时间】:2017-01-30 21:06:14
【问题描述】:

背景

假设我有一个 Azure 表实体

class MyEntity : TableEntity
{
    public string LongString { get; set; }
    public bool IsCompressed { get; set; }
}

如果LongString > 64KB(Azure 对属性的限制),我想将LongString 压缩保存。 为此,我有 Compress(string)Decompress(string) 两个函数

目前,在每次插入之前,我都会检查 LongString 的长度,如果它 > 64KB,我会设置 LongString = Compress(LongString)IsCompressed = true。 每次 Azure get 操作后都相反。

我想从整个代码中隐藏压缩选项,并将压缩和解压缩自包含在 MyEntity 类中。

问题

在从 azure 表获取和设置实体之前和之后是否可以进行自定义操作?有点像...

class MyEntity : TableEntity
{
    public string LongString { get; set; }
    public string IsCompressed { get; set; }

    public override void BeforeInsert()
    {
        if (LongString.Length > 64KB)
        {
            LongString = Compress(LongString);
            IsCompressed = true;
        }
    }

    public override void AfterGet()
    {
        if (IsCompressed)
        {
            LongString = Decompress(LongString);
            IsCompressed = false;
        }
    }
}

【问题讨论】:

  • 一个小的离题评论:鉴于 Azure 使用 UTF16 对数据进行编码,因此使用 2 个字节来保存您提供的每个数据字节,限制实际上是 32KB 而不是 64KB。我想我应该提一下。

标签: c# azure azure-table-storage azure-tablequery


【解决方案1】:

您不需要任何复杂性,只需创建计算属性即可写入表存储。而且您也不需要多个属性。因此,不需要具有 IgnoreProperty 属性的第二个属性。我在文本编辑器中输入了下面的内容,但这应该会给你这个想法。

private string longString;

public bool IsCompressed { get; set; }

public string LongString
{
    get
    {
        return IsCompressed ? DeCompress(longString) : longString;
    }
    set
    {
       if (String.IsNullOrWhiteSpace(value) || value.Length < 64KB)
       {
           IsCompressed = false;
           longString = value;
       }
       else (value.Length > 64KB)
       {
           IsCompressed = true;
           longString = Compress(value);
       }
    }
}

【讨论】:

    【解决方案2】:

    使用ReadEntityWriteEntity 函数找到了解决方案。

    class MyEntity : TableEntity
    {
        public string LongString { get; set; }
        public bool IsCompressed { get; set; }
    
        public override void ReadEntity(IDictionary<string, EntityProperty> properties, OperationContext operationContext)
        {
            base.ReadEntity(properties, operationContext);
    
            if (IsCompressed)
            {
                LongString = Decompress(LongString);
                IsCompressed = false;
            }
        }
    
        public override IDictionary<string, EntityProperty> WriteEntity(OperationContext operationContext)
        {
            if (LongString.Length > 64KB)
            {
                LongString = Compress(LongString);
                IsCompressed = true;
            }
    
            return base.WriteEntity(operationContext);
        }
    }
    

    【讨论】:

      【解决方案3】:

      可能类似于以下代码:

      public bool IsCompressed;
      
      public string StoredString { get; set; }
      
      private string longString;
      
      [IgnoreProperty] 
      public string LongString
      {
          get
          {
              if (this.longString == null)
              {
                  if (IsCompressed)
                  {
                      this.longString = DeCompress(StoredString);
                  }
                  else
                  {
                      this.longString = StoredString;
                  }
              }
              return this.longString;
          }
          set
          {
              if (longString != value)
              {
                  this.longString = value;
                  if (this.longString.Length > 64KB)
                  {
                      IsCompressed = true;
                      this.StoredString = Compress(this.longString);
                  }
              }
          }
      }
      

      但问问自己,总是保存压缩字符串是否更容易。

      【讨论】:

      • 1.我对这个解决方案的问题是我将有 2 个具有相同名称 [L/l]ongString 的属性,我不知道哪个是解压缩的。 2. 不总是压缩的原因是在 azure table 应用程序不太长时(大部分时间)的可读性。
      • 好吧,这似乎是一个正当的理由。
      • 这个答案是最好的,因为它只在需要时解压缩值
      猜你喜欢
      • 2011-11-29
      • 2020-05-21
      • 2016-08-25
      • 1970-01-01
      • 2014-07-04
      • 2019-11-05
      • 2017-10-02
      • 1970-01-01
      • 2015-07-22
      相关资源
      最近更新 更多