Alexander Berl
Alexander Berl
Since 0.7 the storage layer stores an external sequence number and a monotonic time64 timestamp into every document. Until now that information is not returned back when reading from the...
Right now, any index/stream defined will live indefinitely and have every future event/document be checked against it's matcher, even if the stream is known to longer match any future events....
After a crash and potentially broken records, the storage should heal itself. This can be achieved by following steps: - truncate all indexes to valid file sizes (currently throws an...
Following https://github.com/albe/node-event-storage/pull/155, which provides a manual process to recover from a crashed write process, a way to make this (semi-)automatic would be to use proper-lockfile as the locking mechanism and...
**NOTE:** This is just an informational issue and not actionable/not supposed to create a change By default we use native JSON.stringify/JSON.parse for serializing events for storage. In my benchmarks with...
For some use-cases it might be preferable to have partitions split into multiple ordered blocks. The most important use-case is archiving (or even deletion) of old data. Right now, this...
EventStoreDB provides a projection API that can project one or multiple streams into new streams by emitting new events, see https://eventstore.com/docs/projections/user-defined-projections/index.html#functions The API could also provide an `emit` function that...
See #25 - this would allow e.g. a custom security layer to be injected based on the partition metadata (and maybe document header?). The partition metadata should then contain access...
Though I try to avoid external dependencies where they do not solve a complex sub-task better than I could, https://github.com/paulmillr/chokidar could help handling the ReadOnly aspect better cross-platform. Especially on...