# #google-app-engine #go #google-cloud-datastore
#google-app-engine #Вперед #google-облако-хранилище данных
Вопрос:
Я пишу приложение Google App Engine Go, и у меня возникли проблемы с тестированием некоторых функций. Вот несколько примеров кода.Проблема заключается в следующем:
- Я создаю новый элемент и сохраняю его в хранилище данных
- Я делаю поисковый запрос для этого элемента сразу после (например, получение всех элементов в пространстве имен)
- Элемента там нет
Если я запрошу элемент позже (скажем, на последующих страницах), элемент будет найден нормально. Я понимаю, что такое поведение может быть преднамеренным для приложений, развернутых на GAE, но я бы ожидал, что локальное хранилище данных будет мгновенно полезно для запросов.
Могу ли я каким-либо образом принудительно консолидировать хранилище данных и использовать его для таких запросов?
Комментарии:
1. Именно здесь вы начнете переключать свой мыслительный процесс с CRUD на более ориентированный на задачи пользовательский интерфейс.
Ответ №1:
Это называется конечной согласованностью, и это особенность хранилища данных App Engine.
Вы можете использовать метод get вместо запроса, чтобы проверить, был ли сохранен объект.
В Java мы можем задать желаемое поведение локального хранилища данных, изменив параметр run:
По умолчанию локальное хранилище данных настроено на имитацию модели согласованности хранилища данных с высокой репликацией, при этом процент записей в хранилище данных, которые не сразу видны в глобальных запросах, установлен равным 10%.
Чтобы настроить этот уровень согласованности, задайте системному свойству datastore.default_high_rep_job_policy_unapplied_job_pct значение, соответствующее степени возможной согласованности, которую вы хотите видеть в своем приложении.
Я не смог найти что-то подобное для Go.
Комментарии:
1. Вы можете изменить параметр согласованности, но вы определенно не должны этого делать. Весь смысл этого в том, что он имитирует худшую производительность в производстве: если вы измените его, вы не будете проверять поведение своего приложения, столкнувшись с возможной согласованностью.
2. @DanielRoseman Моя система построена так, чтобы обрабатывать конечную согласованность, но для тестирования довольно раздражает, что тест «запустите этот тест, он завершится неудачей с первого раза, но если вы запустите его снова, он должен пройти». что-то в этом роде. Когда я тестирую свои функции, которые полагаются на запросы (которые нельзя изменить), я хотел бы иметь возможность передавать в хранилище данных некоторые тестовые данные и проверять их на месте, а не иметь дело с нечеткими шансами во время тестирования.
3. Я согласен с Дэниелом в том, что тесты более полезны, когда они соответствуют шаблонам использования в производстве. Если у вас есть последовательность запросов сохранения в рабочей среде, вы столкнетесь с той же проблемой, что и при тестировании (я когда-то делал с приложением планирования). И если вы не используете его в производстве, последовательность сохранения и получения будет соответствовать вашим потребностям в тестировании.