Хорошие примеры использования групп сущностей в App Engine с открытым исходным кодом?

Я знаю все подробности о том, как группы сущностей работают в хранилище GAE, но вчера (в App Engine meetup в Пало-Альто), поскольку ведущий объяснял его использование групп сущностей, мне показалось, что я никогда не делал этого использование их в моих собственных приложениях GAE, и я не помню, как они использовались в приложениях GAE с открытым исходным кодом, которые я использовал.

Итак, я подозреваю, что я просто забыл (не замечая или не помню) такие примеры, потому что я просто не привык к ним, чтобы немедленно подключить "использование группы сущностей" к "виду проблем приложения, которые решаются" - - и я думаю, что я должен исправить это, изучив такие источники с этой целью, сосредоточив внимание на том, какую проблему использует EG-использование (то есть, почему приложение работает с ним, но не будет работать или не будет работать без него).

Кто-нибудь может предложить хорошие URL-адреса для такого кода? (Очерки также приветствуются, если они будут сосредоточены на решении проблем на уровне приложений, но не в том случае, если, как я уже видел, они просто сосредоточены на деталях работы EG! -).

Ответ 1

Основное использование групп объектов - предоставить средства для обновления более чем одного объекта в транзакции.

Если вам не приходилось их использовать, считайте свои благословения. Либо вы разрабатываете свои модели данных, чтобы ни одно из двух объектов не нуждалось в обновлении одновременно, чтобы оставаться последовательным, иначе вам это нужно, но вам повезло:)

Представьте, что у меня есть тип объекта Invoice и тип объекта LineItem. Один счет-фактура может иметь несколько связанных с ним LineItems. У моего объекта фактуры есть поле LastUpdated. Каждый раз, когда LineItem добавляется к моему счету, я хочу сохранить текущую дату в поле LastUpdated.

Моя функция обновления может выглядеть так (псевдокод)

invoice.lastUpdated = now()
lineitem = new lineitem()

invoice.put()
lineitem.put()

Что произойдет, если счет-фактура put() завершится успешно, и строка linetem() завершится с ошибкой? Дата моего счета покажет, что что-то обновлено, но фактического обновления (новый LineItem) не будет. Решение состоит в том, чтобы поместить оба puts() внутри транзакции.

Альтернативным решением было бы использовать запрос, чтобы найти дату последнего вставленного LineItem, вместо того, чтобы хранить эти данные в поле lastUpdated. Но это включало бы получение как счета-фактуры, так и всех LineItems каждый раз, когда вы хотели узнать, когда последний раз добавлялся линейный элемент, который стоил вам драгоценной квоты хранилища данных.

ИЗМЕНИТЬ, ЧТОБЫ ОТПРАВИТЬ КОММЕНТАРИИ ПОСЕТИТЕЛЕЙ

Ах. Кажется, я понимаю ваше замешательство. Вышеупомянутые абзацы устанавливают, почему транзакции важны. Но вы говорите, что вас все еще не интересуют группы Entity, потому что вы не видите, как они относятся к транзакциям. Но если вы используете db.run-in-transaction, то вы используете группы сущностей, возможно, не осознавая этого! Каждая транзакция включает в себя одну и только одну группу сущностей, и любая данная транзакция может затрагивать только объекты, принадлежащие к одной и той же группе. см. здесь

"Все операции хранилища данных в транзакция должна действовать на сущности в той же группе лиц".

Что вы делаете в своих транзакциях? Существует множество веских причин использовать транзакции только с одним Entity, который по умолчанию находится в собственной Entity Group. Но иногда вам нужно синхронизировать 2 или более сущности, как в моем примере выше. Если Invoice и LineItem Entities не находятся в одной группе сущностей, тогда вы не можете обернуть их изменения в вызове db.run-in-transaction. Поэтому в любое время, когда вы хотите работать на двух или более сущностях транзакционно, вам нужно сначала убедиться, что они находятся в одной группе. Надеюсь, что это станет более понятным, почему они полезны.

Ответ 2

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

Получение маркеров клиента происходит намного быстрее, поскольку они физически хранятся с объектом клиента. (На том же сервере, возможно, на том же диске)
Я могу изменить маркеры для клиента в транзакции. Я подозреваю, что транзакции причины требуют, чтобы все объекты, на которых они работают, были в одной и той же группе, потому что они хранятся в одном и том же физическом местоположении, что упрощает реализацию блокировки данных.

Ответ 3

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