Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

Normalize absolute TTL expiry semantics for partial update

Đang mở
  • Có gì không ổn?
#113 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

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
28/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
aws, azure, java
Lĩnh vực
backend-api-design, databases, documentation, testing-qa

Hướng nghiên cứu

Bắt đầu bằng cách đọc PR #105 và contract của MulticloudDbClient.update(), sau đó so sánh hành vi của DynamoDB UpdateItem và Cosmos DB patchItem được mô tả ở đây. Giải quyết các câu hỏi về thiết kế trước khi thay đổi các triển khai provider. Được xem là hoàn tất khi cả hai provider đều tài liệu hóa và thực thi cùng một kết quả TTL, các trường hợp không được hỗ trợ đều thất bại trước khi thực hiện I/O với provider, phạm vi kiểm thử conformance xác minh việc hết hạn, và tài liệu về capability, API/SPI, khả năng tương thích và chi phí thống nhất với nhau.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Context

PR #105 adds portable shallow partial update through MulticloudDbClient.update(). During review, the proposed provider-specific TTL-preservation capability was removed because support by only one provider does not establish a useful portable contract.

Current behavior differs across the two participating providers:

  • DynamoDB UpdateItem leaves the existing absolute ttlExpiry value unchanged.
  • Cosmos DB patchItem advances _ts, restarting a relative TTL countdown.

TTL timing is therefore explicitly outside the portable partial-update contract for now. Callers requiring a fixed absolute expiry must not use update() on TTL-bearing items.

Goal

Define and implement one portable absolute-expiry behavior across Cosmos DB and DynamoDB without silent provider divergence.

Design questions

  • Can expiry preservation remain one native write with no pre-read or read/merge?
  • Is SDK-owned absolute-expiry metadata required?
  • How should ETag/concurrency races, RU/request cost, retries, and timeout ambiguity be handled?
  • How should existing provider-native TTL fields and already-stored items migrate?

Acceptance criteria

  • Cosmos DB and DynamoDB expose the same documented result for a partial update on a TTL-bearing item.
  • Any unsupported case is rejected before provider I/O with a normalized error rather than silently diverging.
  • Conformance coverage verifies absolute expiry before and after update on every participating provider.
  • Capability declarations, API/SPI Javadocs, compatibility documentation, and cost implications are aligned.
  • The chosen design documents whether the operation still performs one write with no pre-read.

Related: #105

Ngôn ngữ chính
Java
Star
7
Fork
7
Merge trung bình
1 ngày 19 giờ
Pull request đã merge (30 ngày)
3

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. 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.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/multiclouddb-sdk-for-java

Tất cả issue của microsoft/multiclouddb-sdk-for-java

Issue tương tự

Thêm issue về Java

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.