Skip to content

api.md

Latest commit

 

History

History
131 lines (101 loc) · 9.49 KB

api.md

File metadata and controls

131 lines (101 loc) · 9.49 KB
Raw

Check DynamoDB API coverage

Use this page to decide whether a DynamoDB operation fits your workload. BeyondDB exposes ExtendDB's DynamoDB JSON endpoint, but a protocol handler alone does not establish Cell-backed support. A verified path has a signed AWS SDK or CLI request, a durable Cell commit, and a result checked after owner or process restart. Each fixture proves only its stated cases, not every DynamoDB option or error response.

Label in this page What you can conclude
Cell-backed with restart coverage The stated request path and restart case passed; check the boundary column for unsupported options.
Partial Some options work, but the named alternatives are rejected or unqualified.
Unsupported No compatible Cell path is available through the public endpoint.

The AWS CLI guide shows requests you can try. The implementation record contains the test evidence and open qualification gates.

Tables, items, and reads

Core table, item, read, and transaction operations have Cell paths. Read the boundary column before using an option that changes schema, pagination, or consistency behavior.

Operation or option BeyondDB status Boundary
CreateTable, DescribeTable, ListTables, DeleteTable Cell-backed; signed SDK restart coverage for creation, metadata, and deletion paths Routed creation and large deletion can remain in transitional states while workers resume durable progress.
UpdateTable Partial Billing mode, provisioned throughput, table class, and deletion protection use account Cell metadata. GSI create/delete/update, stream specification, vector updates, and on-demand ceilings are rejected.
PutItem, GetItem, UpdateItem, DeleteItem Cell-backed; signed SDK and owner-restart coverage Conditions and updates run in one owning Cell command. Exact expression compatibility still needs the complete protocol suite.
Query, Scan Cell-backed; signed SDK pagination and restart coverage Query handles hash and sort keys. Scan uses bounded pages and supports parallel segments. Continuation across a directory change needs broader qualification.
BatchGetItem, BatchWriteItem Cell-backed through ExtendDB; process smoke and restart coverage A batch is not a cross-item atomic transaction. Check unprocessed items and retry according to the client contract.
TransactWriteItems, TransactGetItems Durable coordinator and participant paths; cross-Cell SDK hard-restart coverage Conflict and capacity behavior at sustained fleet load is unqualified. GSI propagation remains asynchronous after base commit.
TagResource, UntagResource, ListTagsOfResource Cell-backed; signed SDK restart coverage Table deletion removes tag rows in bounded generation cleanup.

The implementation record maps these paths to tests. The full upstream protocol suite remains an acceptance gate.

Indexes

Local secondary indexes (LSIs) share a base Cell's atomic mutation. Global secondary indexes (GSIs) have separate owner Cells and receive base changes asynchronously.

Feature BeyondDB status
LSI created with a table, ALL projection Implemented with base mutation and index maintenance in one Cell command; account and routed SDK fixtures cover Query/Scan, transactions, and restart.
LSI KEYS_ONLY or INCLUDE Rejected at CreateTable. ExtendDB needs a shared read-plan and base-fetch capacity contract before BeyondDB can return correct attributes.
GSI created with a table Independent range Cells, asynchronous journal projection, and ALL/KEYS_ONLY/INCLUDE Query and Scan paths. Selected signed SDK and recovery tests pass.
Online GSI creation, deletion, or update Rejected by UpdateTable. Index backfill primitives exist, but account lifecycle orchestration and public SDK qualification do not.
Vector indexes and SearchVectors ExtendDB has handlers; BeyondDB rejects vector index creation and has no supported Cell vector path.

See LSI contract and GSI design and limits. Index support does not imply fleet-scale index recovery or a guarantee that a hot partition-key group can grow beyond one Cell.

TTL

Time to live (TTL) removes expired items in background work. Setting an expiration time does not hide the item immediately from reads.

UpdateTimeToLive and DescribeTimeToLive store settings in the account Cell. The serving worker configures a fixed expiry index in data Cells, backfills older items in bounded commands, and conditionally removes expired items. Settings and sweep progress survive owner restart. Expiry is asynchronous. The global TTL listing traits remain unsupported; the worker enumerates each configured account directly. TTL implementation status

Streams

Streams record eligible item changes in the base mutation's Cell command. Reading and retention have additional lifecycle limits.

CreateTable can install a stream policy. Item changes and eligible TTL removals produce records in the same Cell command as the base mutation. ListStreams, DescribeStream, GetShardIterator, and GetRecords can read current and deleted table generations during the 24-hour retention window. A signed SDK write and CLI Streams read survived a hard server restart.

This is partial Streams support. UpdateTable cannot enable, disable, or change the view type. Bounded retention sweeps cover active routed owners and catalog-discovered dormant or deleted data Cells. Expired stream catalog rows, full split-lineage and iterator qualification, and fleet-scale retention work remain open. See Streams contract and implementation status.

Authentication and administration

The signed public endpoint can enforce stored credentials and inline policies. Account administration and credential issuance are separate unfinished surfaces.

The public endpoint verifies SigV4 through ExtendDB. Long-lived credentials, externally provisioned temporary credentials, and revocation use encrypted credential Cells. Inline user/role policies and user/role permission boundaries are Cell-backed; signed tests cover denial and owner restart. BeyondDB does not issue STS credentials. Group policies, session policies and tags, and the management APIs for accounts, users, roles, policies, and keys are unfinished. The server uses a pass-through authorization cache so policy removal takes effect without a stale cached grant. Catalog implementation

Explicitly unsupported or incomplete

These gaps require more than a server configuration change. In particular, the current import/export extensions do not implement DynamoDB's S3 API workflow.

Area Current result
On-demand backup and restore, continuous backup, PITR BackupEngine methods return Unsupported; there is no coordinated table-wide backup cut.
DynamoDB S3 import/export Pinned ExtendDB has local-file, synchronous extensions rather than DynamoDB's S3 workflow. BeyondDB supplies empty allowed path lists, so both handlers reject requests.
PartiQL and Global Tables Pinned ExtendDB does not dispatch these operations. BeyondDB has no Cell implementation or replication protocol for them.
SSE specification and on-demand throughput ceilings Rejected at CreateTable; on-demand ceilings are also rejected at UpdateTable. Table class values are metadata only, without AWS pricing semantics.
Account-wide management, metrics, admin login, STS issuance Cell-backed implementations are absent or explicitly unavailable.
Production-scale and upgrade compatibility 10,000-Cell/multi-TB, sustained load, storage collection, and in-place upgrades of older development roots remain unqualified.

The source gates are in table creation/update, backup methods, and server wiring. For ExtendDB's own standalone feature set, see its differences from DynamoDB.

How to qualify a new API claim

Use the same evidence path for each new operation or option:

flowchart LR
    Compare["Compare ExtendDB SQLite<br/>and protocol behavior"] --> Signed["Send signed AWS SDK<br/>request"]
    Signed --> Commit["Verify durable<br/>Cell result"]
    Commit --> Restart["Restart or replace<br/>the owner"]
    Restart --> Replay["Check result,<br/>replay, and errors"]
Loading
  1. Compare the backend result with ExtendDB's SQLite backend and the upstream protocol suite, including validation and error responses.
  2. Send the operation through ExtendDB's signed public endpoint using an AWS SDK or CLI client. Check that its mutation and result reach a durable Cell commit.
  3. Restart or replace the owner from published object-store state. Replay the request where applicable and verify the data, metadata, and error outcome.
  4. For cross-Cell work, inject failure before and after the coordinator decision and verify idempotent participant resolution.

Until those checks pass, describe a path as implemented or partial rather than generally compatible. The current independent qualification runner supports unchanged ExtendDB Python client tests.