Запрос EventStoreDB с помощью java API или HTTP API

В последнее время я использую блестящую базу данных Event Store от блестящего Грега Янга, и это прекрасно. Но документация ужасна, она устарела, местами некорректна и распространяется через сайт. Иногда вам нужно просмотреть несколько нерелевантных страниц, чтобы сломать код документации!

В любом случае, не только документация, но и Java API отстой, и в большинстве случаев вместо этого вам приходится использовать HTTP API.

Я создал свой собственный Java API на основе HTTP API.

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

Итак, теперь я знаю, как мне создавать новые прогнозы, которые будут создавать потоки, заполненные моими желаемыми событиями, отфильтрованными по заданным критериям в предложении when.

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

У меня возникают трудности с временными запросами. Я не мог найти никакой документации о том, как мне делать запросы. Но я догадался, что сначала нужно создать одноразовую проекцию для каждого запроса, а результаты передать новому потоку с именем query-{id}. Затем я немедленно пытаюсь прочитать события из нового потока запросов, но требуется время, чтобы создать поток запросов и заполнить его результирующими событиями. Итак, мой API для запросов создает проекцию и сразу же запрашивает события в результирующем потоке, но получает 404, что означает, что проекция еще не начала обрабатывать и создавать новый поток.

Итак, есть ли способ передать проекцию для хранения событий и запросить ее для событий?

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

Я создаю новый поток для каждого из моих агрегатов, и все работает нормально. И у меня есть отдельный ограниченный контекст для отчетности всей системы, и он использует MongoDB, и это прекрасно работает. Но иногда мне нужно запросить события, чтобы проверить инварианты. Например, мне нужно проверить, является ли название продукта уникальным или нет, и выдать исключение. Чтобы сделать такую ​​проверку, я должен создать отдельную модель чтения для агрегатов внутри каждого ограниченного контекста. Но я хочу делать такие запросы, просто запрашивая у хранилища событий все события ProductCreated с одним и тем же заголовком, а затем я хочу обработать все эти события, чтобы увидеть, есть ли у нас продукт с таким же заголовком.

Итак, как я могу запросить в хранилище событий все события ProductCreated, где заголовок равен некоторому значению, и немедленно получить результат?

Или, может быть, база данных хранилища событий не предназначена для таких случаев?!


person Masoudy BaBa    schedule 08.09.2020    source источник


Ответы (1)


Сожалеем о вашем опыте работы с документацией. Я не уверен, заметили ли вы, но мы опубликовали новую документацию пару недель назад, и на старом веб-сайте документации в баннере четко указано, что она устарела.

Клиент JVM (не клиент Java) не создан Event Store. Над новым клиентом сейчас ведется работа, но это клиент версии 20.6, который будет поддерживать только gRPC. .

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

Я могу ответить на тот, который я понимаю, о чтении однотипных событий. Система по типу события проекция создает потоки, из которых вы, возможно, захотите читать ($et-ProductCreated в вашем примере), но я не уверен, решит ли это ваш вариант использования, поскольку у вас также могут быть такие события, как ProductRenamed, и вы бы надо тоже разобраться.

Я не рассматриваю этот случай как инвариант, поскольку ваша система вряд ли станет несогласованной, если два продукта случайно получат одно и то же название. Это зависит от количества продуктов, которые вы ожидаете зарегистрировать и переименовать одновременно в системе. Если у вас есть новые продукты, регистрируемые со скоростью 100 продуктов в секунду, вы, вероятно, все равно не сможете прочитать все ProductCreated события, чтобы узнать, является ли новое имя дубликатом другого. Если у вас есть примерно один продукт в час, простая проекция на MongoDB будет самым простым и быстрым способом проверки дубликатов.

Я бы предложил открыть еще один вопрос, касающийся временных запросов.

person Alexey Zimarev    schedule 08.09.2020
comment
спасибо за ваш ответ. я действительно ценю это. ссылка на баннере выше просто перенаправляет на ту же страницу, где говорится, что эта документация предназначена для v5. я сначала установил v20, но у меня было так много трудностей с его использованием, и документация была согласовано с v5. поэтому я переключился на v5, поэтому я пишу новый вопрос, как вы предложили для временных запросов, и сейчас я прокомментирую ссылку здесь - person Masoudy BaBa; 08.09.2020
comment
пожалуйста, проверьте этот последующий вопрос, как вы предложили: stackoverflow.com /вопросы/63795724/ - person Masoudy BaBa; 08.09.2020