2010-02-09 4 views
1

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

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

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

Спасибо и наилучшими пожеланиями Алекс

+1

alexander, я ответил на ваш вопрос с помощью google-app-engine, который является тегом, который стал стандартным здесь, на SO для работы с движком приложения. черточки превращают его в один тег, а не отдельные теги, например, для «приложения» и «движка». –

ответ

1

В порядке:

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

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

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

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

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

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

Смежные вопросы