App Engine — цепочка сущностей генерирует исключительно длинные ключи сущностей

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

Однако проблема с этим подходом заключается в том, что каждый новый объект имеет ключ, который включает в себя весь ключ предыдущего объекта (т. е.: new_top_key == old_top_key + new_stuff). Это приводит к тому, что ключи сущностей растут с большой скоростью и, вероятно, очень плохо ведут себя после нескольких сотен сообщений в одной цепочке (но я на самом деле не проверял).

Итак, мой вопрос: 1) Является ли это преднамеренной функцией App Engine. 2) Должен ли я избегать такого типа структуры — или он каким-то образом эффективно обрабатывается App Engine внутри? 3) Есть ли у вас какие-либо предложения о правильном подходе к структуре типа связанного списка сущностей?

Спасибо и с уважением Алекс


key google-app-engine parent
person Alexander Marquardt    schedule 09.02.2010    source источник
comment
Александр, я перепометил ваш вопрос с помощью google-app-engine, который является тегом, который стал стандартным здесь, в SO, для материалов движка приложений. тире превращают его в один тег, а не в отдельные теги, как у вас было для приложения и движка.   -  person Peter Recore    schedule 09.02.2010

Ответы (2)


arrow_upward
1
arrow_downward

Чтобы:

  1. Да. Каждый объект однозначно идентифицируется своим видом, ключом или идентификатором, а также всеми его родительскими элементами, а это означает, что для идентификации объекта необходима вся цепочка.
  2. Да. Вместо этого создайте объект «диалог» (который также может быть первым сообщением), который является прямым родительским элементом всех сообщений. Если вам по-прежнему необходимо поддерживать отношения родитель-потомок в беседе (вместо того, чтобы просто упорядочивать их, например, по отметке времени), объявите явное свойство SelfReferenceProperty.
  3. См. № 2 выше.
person Nick Johnson    schedule 09.02.2010

arrow_upward
1
arrow_downward

Вы используете питон или java? Подробный ответ будет немного зависеть от того, какой API вы используете.

Я почти уверен, что бесконечное увеличение количества ключей — не лучший план. (хотя это может быть хорошим тестом для API движка приложения :)

Я думаю, что решение будет состоять в том, чтобы отделить информацию о группе сущностей от информации о связывании сообщений. Для выполнения транзакций в потоке/разговоре/цепочке/независимо от того, все ваши сообщения должны находиться в одной и той же группе объектов. Однако они не обязательно должны находиться в иерархии, точно соответствующей структуре связей между сообщениями. Вы должны явно указать родителя (группу сущностей) всех ваших сущностей сообщений, чтобы они были одинаковыми в плоской структуре. Таким образом, каждая сущность будет родственной по отношению к другим в смысле групп сущностей. Вам также понадобится поле в вашей сущности для ссылки на следующее (и/или предыдущее) сообщение. Таким образом, у вас все еще будет связанный список (или дерево или что-то еще) с точки зрения ссылок «предыдущее сообщение».

Как в Python, так и в Java есть методы для создания сущности с определенной родительской/группой сущностей. (Фактически, вы даже можете указать несуществующую сущность в качестве корня иерархии группы сущностей!)

Теперь ключ каждого сообщения будет иметь фиксированную длину, поэтому ваши «следующие» и «предыдущие» ссылочные свойства будут красивыми и защищенными от переполнения некоторого ограничения на длину ключа.

person Peter Recore    schedule 09.02.2010