upstream(tinydb): update/remove by doc_ids skip missing ids silently #135

Tracks upstream friction in TinyDB. The explanation lives in the docs; this issue is the unit of work.

Explanation: Table.update(doc_ids=…) and Table.remove(doc_ids=…) skip missing ids silently — the limitation, why it matters to an ODM, the workaround tinydantic carries, and the change that would remove it. That section is written to be read standalone by an upstream maintainer, so it doubles as the ready-to-send proposal if we ever file this.

Reproduction

Upstream only — no tinydantic import.

from tinydb import TinyDB
from tinydb.storages import MemoryStorage

db = TinyDB(storage=MemoryStorage)
db.insert({"n": 1})

print("update(doc_ids=[1, 999]) ->", db.update({"n": 2}, doc_ids=[1, 999]))
print("remove(doc_ids=[1, 999]) ->", db.remove(doc_ids=[1, 999]))

Run with python repro.py.

Actual output:

update(doc_ids=[1, 999]) -> [1]
remove(doc_ids=[1, 999]) -> [1]

Document 999 does not exist. Both calls operate on document 1, return [1], and report the absence in no other way — the caller has to compare the returned list against the one they passed to notice that the operation they got was not the one they asked for. Before TinyDB 4.9.0 the same calls raised a bare KeyError partway through the updater.

Expected: either a strict= parameter that raises naming the absent ids, or a documented guarantee that the returned list must be compared against the requested one to detect partial application.

Environment: TinyDB 4.9.0, Python 3.10.20, macOS. Run 2026-08-13.

What tinydantic carries today

TinydanticModel._check_doc_ids_exist(), which reads the table once and raises DocumentNotFoundError before any write, keeping update_by_ids()/remove_by_ids()/get_by_ids() all-or-nothing. Cost: one extra table read per id-selected write.

This is a regression introduced by TinyDB 4.9.0 (#591); before 4.9.0 the same call raised a bare KeyError.

Upstream status

Not filed. Upstream changed this deliberately, so a report would be a behavior argument rather than a bug report — worth a maintainer's judgement before drafting.

What would close this

A strict= parameter raising on absent ids, or a documented guarantee that the returned list must be compared against the requested one — or a maintainer decision to carry the workaround indefinitely.

Assisted-by: Claude:claude-opus-5