Согласованные унаследованные свойства между объектами на appengine HRD

Question

Я внедряю файловую систему. Каждая папка имеет ACL, который в основном будет просто списком идентификаторов пользователей, которым разрешено чтение / запись в папку. Я хочу реализовать это путем копирования списков ACL из папок верхнего уровня в папки нижнего уровня - мне нужны унаследованные разрешения, но я не хочу искать их во время чтения. Я храню отношения между папками в виде ссылки на суперпапку в подпапке.

С HRD трудно решить следующий порядок операций:

1. Поместите папку B в хранилище данных как подпапку папки A, которая уже существует.
2. Изменить права доступа на A.

Проблема в том, что когда я изменяю разрешения для A на шаге 2, мне нужно найти все дочерние элементы A, чтобы я также мог применить изменения разрешений для них. К сожалению, это означает запрос, поэтому B может не отображаться в этом запросе. B может пропустить изменения разрешения!

Единственное решение, о котором я до сих пор думал, - это хранить отношения «подпапки» в двух направлениях: A имеет ссылку на все свои подпапки, а B имеет ссылку на свою суперпапку. Тогда я мог бы использовать межгрупповую транзакцию для одновременного обновления A и B, и на шаге 2 не потребовался бы запрос. В любом случае это может быть лучше, поскольку прямые запросы можно легко кэшировать, не требуя сканирования индекса и т. Д.

У кого-нибудь есть еще идеи? Мне не нравятся потребности этого решения в избыточном хранилище или необходимость транзакций XG.

Answer 1

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

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

Если у вас есть структура данных, которая может быстро идентифицировать всех предков иерархии B, вы можете выполнить асинхронное чтение всех предков при определении свойств совокупных метаданных для B и его предков. Вы можете управлять этим, сохраняя полные пути с сущностями. Это включает в себя больше операций с хранилищем данных (порядка длины пути), но не намного больше времени запроса, и вы получите возможность нормализовать эти данные.