Хранилище событий не может записывать в мягкие удаленные потоки - PullRequest
Новая
       62

Хранилище событий не может записывать в мягкие удаленные потоки

0 голосов
/ 02 октября 2018

Чтобы прояснить: этот вопрос о Магазине событий Грега Янга.

Я попытался мягко удалить поток, который содержал 2 события: 

var slice = con.ReadStreamEventsBackwardAsync(streamName, 0, 1, resolveLinkTos: true).Result;
es.DeleteStreamAsync(streamName, slice.LastEventNumber, hardDelete: false).Wait();

Этот вызовБыл успешным, и расследование магазина выявило новое событие метаданных.Это событие было типа $metadata и содержало: 

{
  "$tb": 9223372036854775807
}

$tb обозначает «усечение до» и описано в Удаление потоков и событий .Документация гласит:

Когда вы удаляете поток, его TruncateBefore или $ tb устанавливается на номер текущего события последнего потока.

Какой (как вы можете видеть вJSON выше) не тот случай.Усечение перед установлено на long.MaxVaue.Хотя это кажется плохим поведением, это не настоящая проблема. Проблема в том, что я больше не могу записывать в поток. Вызов следующего фрагмента успешно завершен, но не добавляет событие в поток: 

await es.AppendToStreamAsync(persistenceId, expectedVersion < 0 ? ExpectedVersion.NoStream : expectedVersion, events);

В приведенном выше фрагменте expectedVersion установлено на -1.Метаданные мягкого удаленного потока говорят: 

Stream is deleted: False
Meta Stream version: 0
Truncate before: 9223372036854775807
Max count:
Max age:

И чтение фрагмента из последнего события потока показывает: 

Last Event number: 1
Next Event number: -1
Status: StreamNotFound

Кто-нибудь сталкивался с такой же проблемой и мог найтирешение, которое позволяет продолжать добавлять события в удаленные потоки?

1 Ответ

0 голосов
/ 04 октября 2018

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

Мы создали детерминистический Guid из персистентностиидентификатор и порядковый номер.Это не будет проблемой, если вы не определите порядковый номер на основе количества событий в потоке.Мягкий удаленный поток не возвращал никаких событий, в результате чего новое событие имело порядковый номер 0, и поэтому мы сгенерировали тот же идентификатор события, что и самое первое (но удаленное) событие в потоке.Затем хранилище событий продолжило работу и проигнорировало новое событие, поскольку (на основе созданного идентификатора события) оно уже было сохранено и удалено.

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

...