В блоге уже есть много сообщений о возможности подключиться к событию WritingEntity для настройки XML, отправляемого на сервер, например this .
Что-нибудь изменилось с этим процессом в более новых версиях SDK? Я спрашиваю, потому что у меня есть следующая простая сущность:
public class Label : TableServiceEntity
{
public Guid Id { get; set; }
public string Name { get; set; }
public string Notes { get; set; }
public string ContactInfo { get; set; }
public List<string> Urls { get; set; }
public Label()
{
Urls = new List<string>():
}
}
Я хочу сохранить эту коллекцию URL-адресов, и я уже знаю, что единственное, что напрямую поддерживается в отношении массивов / коллекций, - это двоичные массивы. Итак, я подумал, хорошо, я просто подключусь к этому событию WritingEntity и сериализую этот список в JSON / XML, а затем добавлю его в список свойств в соответствии с этим сообщением в блоге. Затем выполните десериализацию обратно в список во время обработки события ReadEntity.
Однако, когда я делаю это, при вызове SaveChanges в TableServiceContext я получаю исключение DataServiceRequest, которое содержит внутреннее исключение NotSupported с сообщением «Поддерживаются только коллекции сущностей». Это потому, что класс String не наследуется от TableEntity? Что меня смущает, так это то, что когда я проверяю записанный XML, он действительно смог успешно написать собственный XML с дополнительным добавленным свойством, содержащим сериализованный список, несмотря на исключение.
Когда я пытаюсь получить метку через CreateQuery, я получаю то же исключение.
Кто-нибудь может мне сказать, что я здесь делаю неправильно, и как лучше всего справляться с этой ситуацией? Я уже сталкивался с Lokad Cloud за постоянство, но мне это не кажется идеальным, так как варианты запросов для возврата данных слишком ограничены для того, что я хочу сделать.
Я взглянул на прошлые вопросы, но, похоже, никто не обращался к этой проблеме напрямую.
Буду признателен за любой совет!
На основании ответа:
Я не знаю, создалось ли у вас впечатление, что я сериализирую всю сущность вручную? Ключом раздела является просто «LABELX», где X - первая буква свойства Name метки, а ключ строки - просто строковое представление GUID (я знаю, что расточительно хранить оба из них, но я просто пытаюсь встать и бежать в данный момент).
Если вы установили точку останова в первой строке события WritingEntity и проверили XML, находящийся в свойстве e.Data, ничто не будет представлять коллекцию URL-адресов в XML. Не имеет значения, является ли список URL-адресов пустым, нулевым или в нем есть записи - он вообще не отображается в XML, поэтому не имеет значения, какой список я передаю. Поэтому я думаю, что это должно ответить все 4 вопроса.
Внутри события записи объекта на самом деле нет ничего особенного: просто код для сериализации списка в XML, а затем код для добавления свойства в XML, согласно сообщению в блоге - все это выполняется без каких-либо исключений.
ОК, извините, я не упомянул тот факт, что в данный момент я использую только хранилище для разработки. Похоже, проблема заключалась в том, что я создал несколько объектов Label, у которых не было URL-адресов, до того, как я создал те, которые имели, и поэтому информация о схеме в таблице TableContainer не имела дополнительного свойства URL. После того, как я очистил базу данных и добавил полностью заполненный объект перед добавлением чего-либо еще, все заработало ОК!