Как список должен быть представлен в XML?
Вы не опубликовали код для своей мутации или преобразователя, поэтому я просто предполагаю, что проблема заключается в согласованности чтения DynamoDB.
-
Попробуйте добавить
"consistentRead" : trueв шаблон ответа на мутацию в AppSync. -
Создайте оптимистический ответ внутри шаблона ответа, как это
## Raise a GraphQL field error in case of a datasource invocation error
#if($ctx.error)
$util.error($ctx.error.message, $ctx.error.type)
#end
## Pass back an optimistic result from DynamoDB. **
#set ($items = {[{"key":"setting_a", "value": $ctx.args.setting_a}, {...}]})
$util.toJson($items)
8 ответов
Для расширяемости я использовал бы первое решение (то с дочерним узлом). Если Вы когда-нибудь хотите хранить какие-либо данные обо всех детях затем, у Вас есть удобный узел, в который можно поместить атрибуты.
Я включил бы его в объект для различения его от других элементов.
Это не имеет большое значение, если названия элементов в списке всегда являются тем же, потому что при обработке его с помощью XPath или Linq-to-XML или безотносительно затем, запрос будет просто иметь еще один селектор, если будет узел обертки, но иначе будет идентичен.
С другой стороны, если имена элементов в списке могут отличаться, то он может сделать обработку списка легче, если существует элемент обертки, потому что можно просто использовать '*' в качестве селектора ниже элемента списка вместо того, чтобы иметь необходимость отфильтровать все элементы тем, которые имеют указанный набор имен.
Таким образом, это, вероятно, не имеет значения чрезвычайно, но я склонен предпочитать иметь элемент обертки просто, потому что это визуально формирует рисунок объектов в наборе от объектов, которые не являются.
Думайте о нем в коде, который требуется написать против него.:
Мне...
spouse.children = person.children...
намного более хорошо семантически, чем...
for child in person:
spouse.addChild(person.child)
Первый работал бы вполне прилично на простые списки, но что, если бы список содержал сам вложенный список?! Что, если элемент имел пару различных списков? Для хранения вещей последовательными, я предпочитаю элемент для списка и использования <item> тег или что-то для дочерних данных. Это поможет использованию родовой функции проанализировать все списки.
Если нам будет нужно универсальное представление XML списка, то мы придем к заключению, что своего рода следующее представление должно использоваться:
<_listSomeName>
<_listItem>...</_listItem>
<_listItem>...</_listItem>
<_listItem>...</_listItem>
<_listItem>...</_listItem>
<_listItem>...</_listItem>
</_listSomeName>
Давайте проанализируем это:
<_listSomeName>элемент обертки необходим, потому что мы можем иметь два или больше списка как дети элемента и должны смочь исключительно и удобно определить каждый список. Часть "SomeName" служит, чтобы сделать уникальное имя списка.<_listItem>элемент необходим для обертывания каждого отдельного элемента списка. Это не может быть опущено, потому что элемент списка может иметь сложную структуру (такой как являющийся самим фрагментом XML), и это было бы сложно для идентификации его как одно целое.
Я использовал бы первое решение. Список имеет семантическую уместность: это - набор подобных элементов и поэтому должно быть идентифицирующееся как таковой. Во втором решении список не существует как элемент.
По моему скромному мнению, это зависит от домена.
Для примера Вы дали, я буду использовать объект для включения детей, потому что сами дети являются не обязательно свойствами человека, но список детей.
Кроме того, использование корпуса поможет, если когда-нибудь необходимо сериализировать/десериализовывать.