Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Portable document key fields differ across Cosmos/Dynamo and read/query (id vs sortKey)

Aperta
  • Qualcosa non va?
#121 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

@allenkim0129 ci sta già lavorando.

Dal 5/10/2026.

Valutazione

Questa issue non è ancora stata valutata.

Descrizione

Summary

The portable document payload has inconsistent key fields across Cosmos DB and DynamoDB, and also between Cosmos read() and portable query().

This is visible with the official Risk Platform sample, which supplies an application id matching the logical sort key. A provider-neutral document viewer cannot render the same field set without provider-specific rules and ambiguity over whether id is application data or a physical key.

Important distinction: the guide intentionally documents different physical key mappings and key-authoritative writes. This issue does not claim that Cosmos storing its key as id is itself a defect. The request is to define and implement a consistent portable result contract, especially the current point-read/query discrepancy, and clarify collision handling for application id.

Reproduction

Tested directly through the Java SDK, bypassing any UI or bridge:

  • multiclouddb-api, Cosmos and Dynamo providers: 0.1.0-beta.2
  • Azure Cosmos Java SDK 4.78.0 (application-bundled dependencies)
  • Windows 11, Java 17, local Windows Cosmos emulator in Gateway mode, DynamoDB Local in shared-db mode
  • Also inspected current upstream main at 9d85a9e6b221a41cac79298ab1295cb9890eb671; the relevant injection/stripping logic remains present. Current main was inspected, not built/runtime-tested.

Run the following against an already-provisioned collection for each provider. Use the same payload and logical key, with a fresh partition for isolation:

var address = new ResourceAddress("repro", "documents");
var key = MulticloudDbKey.of("probe-" + UUID.randomUUID(), "s");
var input = Map.<String, Object>of("id", "s", "name", "probe");

try {
    client.upsert(address, key, input);
    System.out.println(client.read(address, key).document());
    var page = client.query(address, QueryRequest.builder()
        .partitionKey(key.partitionKey())
        .maxPageSize(10)
        .build());
    System.out.println(page.items());
} finally {
    client.delete(address, key);
}
Actual output

Here p abbreviates the generated partition key. Field order is immaterial:

Provider / operation Returned document
Cosmos read() {"name":"probe"}
Cosmos portable query() {"name":"probe","id":"s","partitionKey":"p", ...Cosmos system metadata...}
Dynamo read() {"name":"probe","id":"s","partitionKey":"p","sortKey":"s"}
Dynamo portable query() {"name":"probe","id":"s","partitionKey":"p","sortKey":"s"}

Additional cases reproduced:

  1. No input id: Cosmos read returns only the application fields, Cosmos query includes id/partitionKey; Dynamo read and query include partitionKey/sortKey.
  2. Input id equals sort key: output as above; Cosmos point read removes even the id originally supplied by the caller.
  3. Input id differs from sort key: Cosmos overwrites it with the logical key on write and removes it on read; Dynamo preserves the supplied id alongside the injected sortKey. The Cosmos overwrite is consistent with documented key authority, but application-field preservation is consequently not portable.

Temporary probe records were deleted and absence was verified after each case. No sample records were modified.

Relevant implementation

  • CosmosProviderClient: write paths inject physical id and partitionKey; read() removes every CosmosConstants.SYSTEM_FIELDS entry; query results retain physical fields.
  • CosmosConstants: SYSTEM_FIELDS includes FIELD_ID and FIELD_PARTITION_KEY as well as _rid, _self, _etag, _attachments, _ts.
  • DynamoProviderClient: write paths inject partitionKey/sortKey, preserving unrelated id; reads return these attributes.
  • Guide: Document Field Injection documents provider-specific physical mappings. This needs to be distinguished from portable returned-payload semantics.

Requested contract / acceptance criteria

  • Define a single portable representation for logical keys and application payloads, shared by read() and portable query() across providers.
  • Decide whether keys live in result metadata or normalized document fields; avoid requiring consumers to infer provider-native key names.
  • Explicitly define reserved names and collision behavior for application id, partitionKey, and sortKey. Do not silently discard genuine application data merely to make output shapes match.
  • Keep native/raw inspection available separately where appropriate.
  • Add cross-provider conformance coverage for no id, matching id, conflicting id, explicit payload sortKey, and partition-only keys; compare point-read and query results.
  • Cover create/upsert/update round trips and align change-feed document semantics with the agreed contract.
  • Provide compatibility/migration guidance for existing data and callers.

Related: microsoft/multiclouddb-sdk-for-java#64 mentions Cosmos query system-field leakage; this report adds a focused executable reproduction of key-field and application-id inconsistencies. Coordinate with the neutral document/result contract work in microsoft/multiclouddb-sdk-for-java#116.

Lingua principale
Java
Stelle
7
Fork
7
Merge medio
1g 19h
PR unite (30g)
3

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/multiclouddb-sdk-for-java

Tutte le issue di microsoft/multiclouddb-sdk-for-java

Issue simili

Altre issue su Java

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.