Command handling and version conflicts
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
- 20/100
Hướng nghiên cứu
Start by reading the command handling flow and aggregate event handling code; the issue does not name specific files or tests. Determine how original events and optimistic concurrency retries should work, including whether retry is optional or the default, then define tests for the chosen behavior. The issue leaves these design decisions unresolved, and its last comment was 657 days ago.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
The current command handling flow looks like this:
- Load the aggregate
- Call the model
- Persist new events
When the last step fails due to an optimistic concurrency exception, an external policy can retry the operation because the domain models to retry blindly. However, the stream is loaded again, because the retry happens on the outside. Also, we need to read the stream to get new events that caused the conflict.
However, it's possible to react to the optimistic concurrency exception by reading the stream tail from the last known event version. For shorter streams, the difference would be marginal, but for streams longer than a hundred events it would presumably be faster as we'd only need the stream tail, which most probably only has one event that caused the concurrency exception.
A prerequisite for this would be that the aggregate object contains the list of original events in addition to the list of new events as it does today. Opening up the list of original events for access has other benefits that I would be describing here.
I guess that the optimistic concurrency retry needs to be optional as it's not always the desired default behaviour of the model. The question would be if it should be the default or not...
- 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 2 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 2 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 8 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 8 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ự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
Maintainer thường phản hồi trong vòng 1 ngày
-
bug priority: P2
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 78/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 76/100
IridiumIO/CompactGUI#699 ·
Maintainer thường phản hồi trong vòng 3 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
bitfoundation/bitplatform#14070 ·
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 73/100
Maintainer thường phản hồi trong vòng 1 ngày