CocoIndex 1.1 fixes connector key collisions CocoIndex 1.1 fixes connector key collisions

Identity controls updates and deletions

CocoIndex matches source items and target states against previous runs using their keys. A collision can therefore overwrite a different object or remove its output. The release repairs collisions across storage, graph and vector-database connectors. It also fixes deletion failures that left stale rows behind. Object-storage prefixes now identify folders: a prefix of docs includes docs/a.md, but excludes docsa.md. Outputs previously included by that broader match are removed on the next update. Filename-prefix filtering remains available through path_matcher.

Drive files keep their own identity

The Google Drive connector now keys iteration by file ID, which stays stable when a file is renamed. Two files can share a display name, including inside the same folder, without sharing that key. When configured roots overlap, the connector emits a reachable file once. It chooses the first path encountered in breadth-first traversal, with children ordered by name and then ID. Binary-file change detection uses Drive’s MD5 checksum. Workspace documents have no such checksum, so exported content is hashed instead.

Switching graph APIs takes two updates

The Neo4j and FalkorDB guides describe the transition from table and relation targets to node and relationship targets. First, an update records declarations as user-managed. That changes CocoIndex’s ownership state without changing the database. A second update replaces the old declarations with the new APIs and restores system management. Constraints and indexes remain; records are rewritten once, vector indexes rebuilt, and derived edge IDs replaced. Tables can move individually because new relationship targets accept endpoint tables from either API.

Kafka migration includes replay

Kafka’s replacement map-feed pattern separates topics into individual consumers and component paths. Previously, identical message keys on different topics could refer to one item; a deletion on either topic could remove the other’s output. The documented switch changes item keys. Committed offsets alone would leave old components behind and populate new ones only with subsequent messages. The migration therefore removes the old app’s outputs and replays retained topic history from the earliest offsets. Replacing a one-element topic list with a single topic string preserves keys and needs no such replay.

Reprocessing is connector-specific

The release identifies several first-update effects. Google Drive components receive new keys and are reprocessed. SurrealDB relationships without explicit IDs are recreated under different record IDs. Local directory outputs with newly normalized names are written once. Separate memoization changes can also alter generated IDs for values containing shared subobjects, affecting row keys built from those IDs.