Лазурный стол для хранения данных и миграция данных

Question

Возможно ли использовать рефакторинг TableEntities, используемый для хранения таблиц Azure? Например, рассмотрим следующий объект:

class MyEntity: TableEntity 
{ 
    public string SomeID { get; set; } 
} 

Можно ли поддерживать значения при выполнении рефакторинга, как:

• переименовании SomeID к SomeOtherID?
• Изменение типа недвижимости с string по Guid? (учитывая, что все существующие значения являются фактическими идентификаторами GUID)

Если да, то каков рекомендуемый подход для последовательного изменения этих схем, например миграции для EF6?

Answer 1

Одним из вариантов, которые вы могли бы изучить, является использование настраиваемого преобразователя EntityProperty.

Если изменить имя свойства в классе от SomeID к SomeOtherID и вставить объекты с новым именем для хранения таблицы, вы будете иметь объекты с SomeID и/или SomeOtherID полей в табличном хранении.

Когда вы запрашиваете их обратно, вы можете предоставить пользовательский делегат EntityProperty Resolver, который будет использоваться SDK для хранения, чтобы создать из словаря свойств свойства конкретный тип объекта. В этом делетете вы можете поместить логику для обработки этого сценария, чтобы создать нужный тип.

Перегруженный ExecuteQuery метод CloudTable принимает EntityProperty распознаватель:

public virtual IEnumerable<TResult> ExecuteQuery<TResult>(
    TableQuery query, 
    EntityResolver<TResult> resolver, 
    TableRequestOptions requestOptions = null, 
    OperationContext operationContext = null 
) 

И EntityProperty распознаватель является делегат, где вы решаете, как построить свой сильный тип объекта из словаря собственности:

public delegate T EntityResolver<T>(
    string partitionKey, 
    string rowKey, 
    DateTimeOffset timestamp, 
    IDictionary<string, EntityProperty> properties, 
    string etag 
); 

Так в этом делетете вы добавляете код для обработки kvp s с ключами SomeID и SomeOtherID при построении возвращаемого значения типа T.

Вы также можете использовать то же самое для обработки изменений типа. Вставьте новую схему и измените тип свойства, и когда вы прочитаете ее обратно, обработайте их в своем EntityProperty resolver.

Я бы по-прежнему рекомендовал перенос данных в новую модель данных вместо поддержки пользовательских преобразователей. Пользовательские преобразователи могут помочь вам, пока вы находитесь в середине процесса переноса данных и все еще обслуживаете запросы, находясь на этом этапе перехода.

Answer 2

Я не думаю, что есть способ сделать это из архитектуры Azure Storage. То, что вы можете сделать, это просто прочитать объекты и обновить их один за другим (или пакетный пакет с использованием EntityGroupTransaction).