Деревья объектов Google Cloud DataStore от json - PullRequest
0 голосов
/ 03 мая 2018

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

const Datastore = require('@google-cloud/datastore');
const datastore = new Datastore({
  projectId: 'MY_PROJECT_ID',
});

const ot1 = {
  // The kind and ID for the new entity
  key: datastore.key(['OT', '1']),
  data: {
    obj: [
      {
        var1: 'var1',
        var2: 'var2',
      },
      {
        var3: [{obj2:'var3'}, 'var5'],
        var4: 'var4',
      },
    ] // obj
  } // data
};

datastore.save(ot1);

Если я сейчас проверю свое хранилище данных, оно содержит одну сущность 'obj' типа Array (как и ожидалось), но значением является один большой двоичный объект JSON, представляющий массив, т. Е. Я не могу углубиться в объекты-потомки (которые * 1004) *, obj[1], obj[1].var3 и obj[1].var3[0]) из консоли хранилища данных (в то время как с AWS DynamoDB и тем же JSON я могу выполнить детализацию, как будто она автоматически выполняет преобразование из объектов JS в формат БД ). Тем не менее, документы указывают, что родительский объект не может быть изменен после создания объекта, поэтому родительский объект должен быть создан до дочернего объекта. Похоже, что API требует, чтобы я сохранил в несколько шагов:

  1. Сохранить корневой объект с пустым списком
  2. Сохраните каждого потомка root, установив для его родителя root (obj); непонятно, как добавить каждого потомка в массив; obj[1] будет иметь пустой массив как var3 значение свойства
  3. Сохранить каждый элемент массива obj[1].var3, установив для его родителя значение obj[1]; та же проблема с массивом

Это много работы, конечно, есть библиотечная функция, которая делает это автоматически, но я не могу ее найти. И я не уверен, как это будет выглядеть в консоли Datastore, я подозреваю, что в итоге вы получите 4 объекта, то есть иерархия будет известна только косвенно, если наблюдать родительские свойства.

Обновление : Я подозреваю, что ответ заключается в использовании ORM, такого как js-data.

Ответы [ 2 ]

0 голосов
/ 01 июня 2018

Вы сказали:

"родительский объект нельзя изменить после создания объекта, поэтому родительская сущность должна быть создана перед дочерней сущностью "

Но я думаю, что это не совсем так, поскольку в документации сказано ...

"Поскольку это часть ключа сущности, идентификатор связан навсегда с сущностью и не может быть изменено . " [1]

а также:

"Когда вы создаете сущность, вы можете при желании назначить другую сущность в качестве родителя; новая сущность является дочерней по отношению к родительской сущности (обратите внимание, что в отличие от файловой системы, родительский объект не должен на самом деле существует ). " [2]

В любом случае, если вы не можете работать так, как вы хотите на своем языке (Node.js), и решений, предоставленных Дэном Корнилеску, вам недостаточно (или даже если они есть), вы всегда можете открыть запрос на будущее здесь о ваших проблемах с облачным хранилищем данных в Google issetracker с компонентом «Общедоступные трекеры> Cloud Platform> Хранилище и базы данных> облачное хранилище данных» (например, [3] )

1.- https://cloud.google.com/datastore/docs/concepts/entities#kinds_and_identifiers

2.- https://cloud.google.com/datastore/docs/concepts/entities#ancestor_paths

3.- https://issuetracker.google.com/issues/new?component=187197&template=1010240

0 голосов
/ 03 мая 2018

ИМХО, невозможно автоматически сохранить данные json в структурированном формате без указания этого структурированного формата - как будет решено, должна ли конкретная часть данных действительно быть отдельной сущностью или просто помещена в одну и ту же сущность? - любой из них может быть желательным в зависимости от применения.

Не совсем уверен насчет go (я не пользователь go), но в python есть поддержка Структурированные свойства , которые позволяют выполнять запросы ниже уровня свойства.

Я вижу, что go также поддерживает Структурированные свойства , но я не нашел хороших ссылок на запросы и их массовое заполнение. От Свойства и типы значений :

Вы также можете использовать struct или slice для агрегирования свойств. Увидеть Ссылка на хранилище данных Cloud для более подробной информации.

Это был бы как-то похожий вопрос, но для python (он включает в себя указание структурированного формата): Как лучше всего заполнять StructuredProperty через конструктор ndb.Model? Может быть аналогичный подход может быть применен в go.

I думаю это тоже может быть актуально: хранилище данных: получение ключа объекта в виде поля структуры # 453

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...