Google Appengine: Это хороший набор групп объектов?

Question

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

Я делаю художественный сайт, на котором участники могут зарегистрироваться как обычный пользователь или как один из нескольких типов неполиморфных сущностей (Artist, Venue, Organization, ArtistRepresentive и т. Д.). Художники, например, могут иметь Художественное произведение, которое, в свою очередь, может иметь другие Отношения (Галерея, Медиа и т. Д.). Все эти вещи связаны через ссылки, и я понимаю, что вам не нужны группы сущностей, чтобы просто делать ссылки. Тем не менее, некоторые ссылки должны существовать, поэтому я смотрю на группы сущностей.

Из документов: "Хорошее практическое правило для групп сущностей состоит в том, что они должны иметь размер данных одного пользователя или меньше".

Тем не менее, у меня есть пара, надеюсь, да / нет вопросов.

Вопрос 0: Я так понимаю, вам не нужны группы сущностей только для выполнения транзакций. Однако, поскольку группы объектов хранятся в одной и той же области большой таблицы, это помогает сократить проблемы согласованности и условия гонки. Это честный взгляд на группы сущностей и транзакции вместе?

Вопрос 1: Когда дочерняя сущность сохраняется, получают ли какие-либо родительские объекты неявный доступ / сохраняются? т.е. если я настроил группу сущностей с помощью пути Member/Artist/Artwork, если я сохраню объект Artwork, обновляются ли объекты Member и Artist? Я думаю, что нет, но я просто уверен.

Вопрос 2: Если ответ на вопрос 1 - "да", доступ / обновление только перемещаются по пути и не влияют на других детей. т.е. если я обновляю Artwork, никакие другие дочерние объекты Artwork члена не обновляются.

Вопрос 3: Предполагая, что очень важно, чтобы элемент "Член" и связанный с ним тип учетной записи существовали, когда пользователь регистрируется, и что только пользователь будет обновлять свой элемент "Член" и связанный объект "Тип учетной записи", имеет ли смысл объединять их в группы объектов??

т.е. член / исполнитель, член / организация, член / место проведения.

Точно так же, если только пользователь сможет обновлять объекты Artwork, имеет ли смысл их включать? Примечание. Медиа / Галерея / и т. Д., Которые являются ссылками на Художественное произведение, могут относиться ко многим Художественным работам, а не только к тем, которые принадлежат пользователю (то есть ко многим отношениям).

Имеет смысл иметь все пользовательские биты в группе сущностей, если она работает так, как я подозреваю (т. Е. Q1/Q2 - "нет"), поскольку все они будут находиться в одной и той же области BigTable. Однако добавление графического объекта в группу сущностей может привести к нарушению принципа "держать его маленьким" и, честно говоря, может не потребовать участия в транзакциях, за исключением сохранения пропускной способности / повторных попыток, когда пользователи загружают изображения художественного произведения.

Какие-нибудь мысли? Я неправильно обращаюсь к группам сущностей?

Answer 1

• 0: вам нужны группы объектов для транзакций между несколькими объектами
• 1: изменение / доступ к дочерним элементам не изменяет / не обращается к родительскому элементу
• 2: N / A
• 3: Звучит разумно. Мне кажется, группы сущностей не должны использоваться, если вам не нужны транзакции между ними.

Нет необходимости иметь произведение в детстве в целях разрешения. Но если вам нужно изменить их транзакции (включая, например, создание и удаление), это может быть лучше. Например: если вы удаляете учетную запись, вы удаляете сущность пользователя, но перед удалением дочернего элемента вы получаете DeadlineExceeded или сервер падает. Теперь у вас есть осиротевшее произведение искусства. Если у вас есть более 1000 произведений для художника, вы должны удалить в пакетном режиме.

Удачи!