IDs & IdMap
Entities are referenced by id, never by pointer or index into a Vec that could shift. The core rule: an id is never reused, and an undo puts an entity back under the id it had. Commands, selections and ids handed to MCP clients therefore stay valid across any undo/redo.
Id kinds
| Id | Allocated by / scope |
|---|---|
MediaId, TimelineId, FolderId | Key of an IdMap in Project; project-wide, never reused. |
ClipId | Counter Project::alloc_clip_id; project-wide. Clips live in Vecs inside tracks, not in an arena. |
LinkGroupId | Counter Project::alloc_link_group_id; project-wide. |
MarkerId | Timeline::alloc_marker_id; unique within its timeline. |
A timeline that comes from elsewhere (OTIO import, duplication) gets fresh clip and link-group ids from reallocate_clip_ids, with its crossings remapped.
IdMap
IdMap<K, V> (id_map.rs) is a BTreeMap plus a next counter. Iteration is in id order, which is insertion order.
| Method | Use |
|---|---|
insert(v) | Allocates a new id and stores the value. |
alloc() | Reserves an id now for a command that inserts later, so a redo restores the same id. |
insert_at(id, v) | Puts an entity back under an id allocated earlier (undo of a delete). |
remove(id) | Removes; the id is never handed out again. |
On disk
An IdMap is saved as (next: N, items: {id: value, …}). next is persisted because deleted entities can still be referenced (an offline clip); loading rejects an item id not below next.
LEGACY_SLOTMAP. Projects saved before IdMap (2026-09) used slotmap::SlotMap. legacy_slotmap.rs reads their slot lists and (idx, version) keys, keeping the version so a key to a deleted entity never resolves to a slot's new occupant. It is meant to be deleted once those projects no longer need to open.
No comments to display
No comments to display