Archive of non-existent streams
Maintainer thường phản hồi trong vòng 7 ngày
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 15/100
Hướng nghiên cứu
The issue describes archive and hot store behavior in Eventuous, with EventStoreDB (ESDB) and Elastic as the stores; it names no files or tests. Start by reading the archive loading and appending paths, then trace how unarchiving would interact with subscriptions and the archive connector. Done means choosing and implementing a strategy that preserves optimistic concurrency without duplicate archive reads or unwanted subscription effects.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Aiming to solve the following scenario:
- We are importing data from a legacy system directly to the events archive (Elastic)
- There's one event per aggregate in the archive, its version is zero
- When executing a command on an aggregate, events can only be found in the archive
- When appending the event to the hot store (ESDB), we provide the expected version = 1
- The append fails as ESDB doesn't have the stream
It doesn't work as the archive use case expected all the events to be first appended to the hot store (ESDB), and then archived rea time. The hot store stream gets truncated by time or size, so the stream version is kept although events are gone.
One thing we tried is to put the expected version to the meta. However, it effectively disables the native optimistic concurrency checks provided by ESDB or any other store that keeps the event number per stream as a unique constraint. In that case, this complexity moves to Eventuous code, which is not desirable.
Proposed solutions:
- Append dummy events to the imported streams when importing to the archive, then delete those streams. Pro: everything works as it should, no code changes are required in Eventuous. Cons: ESDB data set will include metadata for all the deleted streams. We are talking about hundreds of millions of streams, and most of them will never get new events, so having all those streams in ESDB is inefficient.
- When loading the aggregate, read events from the archive (as it works today) and append them to ESDB right after. Basically, it's an "unarchive on load" feature. Pros: little code change needed, everything will work as it should. Cons: there's no guarantee that any append will happen after load. It would work quite ok if the aggregate state is only loaded for executing commands, and not for queries.
- Unarchive the stream when appending new events. Pros: events will be appended to the hot store if the command execution produced new events. Cons: more code changes are required, as the aggregate needs to keep the collection of original events for unarchiving purposes.
Both unarchiving strategies have two potential issues:
- Unarchived events will get to all the subscriptions, potentially resulting in undesired side effects
- The connector will try to archive those events too, which will cause data duplication, and the next read will get the archived events twice (unless it fails with a duplicate message-id during the archive)
Potential solutions:
- Force delete stream after unarchive
- Annotate specific (import) events so they aren't archived. With this, we'll have a more generic function to prevent some events from being archived at all, which might be useful (but dangerous). It will also spread out to the connector.
- Ngôn ngữ chính
- C#
- Star
- 512
- Fork
- 99
- Merge trung bình
- 5 ngày 6 giờ
- Pull request đã merge (30 ngày)
- 5
Chuẩn bị môi trường
- Có Dockerfile hoặc tệp Docker Compose
- Không có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của Eventuous/eventuous
-
MongoDB integration tests fail on newer GitHub Actions runner kernelsCó thể đã có người làm @nmummau đã nhận 6 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
Eventuous/eventuous#626 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
-
`dotnet format style --verify-no-changes` fails with naming violations and unnecessary importsCó thể đã có người làm @nmummau đã nhận 6 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 80/100
Eventuous/eventuous#624 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
Eventuous/eventuous#627 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
-
SQL Server: `append_events` does not need the `@inserted` table variableCó thể đã có người làm @nmummau đã nhận 12 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 20/100
Eventuous/eventuous#619 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
-
SQL Server: stream reads do one key lookup per event, and `IDX_EventsStream` duplicates `UQ_StreamIdAndStreamPosition`Có thể đã có người làm @nmummau đã nhận 12 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 18/100
Eventuous/eventuous#618 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 7 ngày
Tất cả issue của Eventuous/eventuous
Issue tương tự
-
area:jobads-cv BE P3
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 74/100
klasolsson81/jobbliggaren#2240 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
k2-fsa/sherpa-onnx#4100 ·
Maintainer thường phản hồi trong vòng 2 ngày
-
:watch: Not Triaged
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
unoplatform/uno.check#591 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100
weaviate/csharp-client#378 ·