Хранилище таблиц Azure и нулевые значения свойств - вводящий в заблуждение документ?

Question

Документация гласит следующее:

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

Я выделил интересующий меня текст.

На первый взгляд мне показалось, что напечатанных свойств сущности никогда не будет null после чтения сущности из строки.Это, конечно, не соответствует действительности, проверено тестированием.

Я явно неправильно прочитал документацию.Эта документация конкретно относится к поведению ответа REST, поэтому в действительности происходит то, что в ответе REST просто пропускаются свойства, для которых не сохранено значение.Таким образом, не сохраняя никаких значений null, любые свойства в результатах REST гарантированно будут ненулевыми, а те, которые были бы null, просто отсутствуют в ответе (до тех пор, пока объект с нулевыми свойствами)заменяется, а не объединяется, когда записывается).

Следовательно, недостающие свойства в ответе REST, сопоставляемые с ITableEntity реализациями, ДОЛЖНЫ быть выведены как null.

Кроме того, дляубедитесь, что значения null действительно "сохранены", сущность должна быть заменена, а не объединена.

Является ли мой анализ правильным?

Если да, то не должна ли документация бытьобновлен, чтобы сделать это понятнее?Это немного сбивает с толку.

Answer 1

Документация означает, что свойство значения null не будет сохранено в таблице хранения Azure service , которая не имеет ничего общего с реализацией библиотеки client .Обратите внимание, что this является документацией REST API , а не документацией клиентской библиотеки .В текущей реализации клиентской библиотеки отсутствующие свойства в ITableEntity сохраняются как null при десериализации ответа на запрос от службы таблиц хранилища Azure.

Значение свойства null будет никогда не будет сохраняться на стороне обслуживания независимо от выполнения операции replace или merge.

Например, если ранее сохраненный объект имеет значение {"a":1, "b":2} на стороне службы, а операция mergeвыполненный с полезной нагрузкой {"a":null, "b":3, "c":4}, вновь сохраненный объект будет {"a":1, "b":3, "c":4} на стороне обслуживания.Для сравнения: если выполненная операция равна replace с полезной нагрузкой {"a":null, "b":3, "c":4}, вновь сохраненный объект будет {"b":3, "c":4} на стороне обслуживания.