dodil data object destination

Manage object-pipeline destinations. Five subcommands — create, list, get, update, delete (dest is an accepted alias). An object pipeline is the facet whose destination writes derived files back into a bucket: a summarizer that drops .md files under summaries/, a transcriber that writes .txt next to each media file. Like the vector facet, the destination is a pipeline, so get, update and delete take a pipeline id.

Persistent flag on the whole group: --bucket / -b (required).

The old objects/destinations route tree is gone. The pillar split folded object destinations into pipeline facets — creating one is POST /:bucket/pipelines/object, listing is ?facet=object. The predecessor dodil.data.object.v1.ObjectService.CreateObjectDestination (which made a bare destination and left binding a pipeline to a second call) no longer exists; template_id is now required and both rows are written together.

dodil data object destination create

dodil data object destination create [name] -b BUCKET \
  -t TEMPLATE_ID --target-prefix PREFIX \
  [--target-bucket BUCKET] [--excluded-prefix PREFIX] [-d DESC]

Creates an object pipeline + its destination in one call (template-driven). K3 writes the store_entities destination row and the pipelines row bound to it together — if the pipeline row fails, the destination is rolled back. The pipeline runs the template against each matching object and writes the derived blob to a deterministic key derived from the source key plus target_prefix.

# Summarize every uploaded doc, write the summary back under summaries/
# (this is what `recipe install summarize-to-markdown` does under the hood)
dodil data object destination create doc-summaries -b kb-prod \
  --template summarization \
  --target-prefix summaries/ \
  --description "Markdown summaries of uploaded documents"

--excluded-prefix exists to stop an ingest cycle. Without it, a destination that writes back into the same bucket re-ingests its own output forever. Ingest rules skip any source object under a destination’s excluded_prefix; when unset the server uses _pipeline-out/. If your target_prefix is a folder your rules also read from, set --excluded-prefix to the same value.

The response is a Pipeline with its destination attached. Capture pipelineId — get, update, delete and every ingest command key off it.

It does not create an ingest rule

Like every facet creator, CreateObjectPipeline derives no ingest rule — callers own rule scope. Nothing is ever processed until you bind one:

dodil data ingest add doc-rule -b kb-prod \
  --source "$SOURCE_ID" \
  --collection "$PIPELINE_ID" \
  --include '**/*.pdf' --include '**/*.docx'

--collection on ingest add sets CreateRuleRequest.pipeline_id — pass the pipeline id regardless of facet. See dodil data ingest. The one shortcut that binds the rule for you is dodil data recipe install — e.g. the summarize-to-markdown recipe wires an object pipeline and its rule in one command.

dodil data object destination list

dodil data object destination list -b BUCKET

ListPipelines with facet = PIPELINE_FACET_OBJECT (?facet=object over HTTP). The response key is pipelines.

dodil data object destination list -b kb-prod -o json \
  | jq '.pipelines[] | {pipelineId, name: .destination.name,
                        targetPrefix: .destination.object.targetPrefix,
                        targetBucket: .destination.object.targetBucket}'

dodil data object destination get

dodil data object destination get [pipeline-id] -b BUCKET

Takes a pipeline id. Read .destination.object for the targetPrefix / targetBucket / excludedPrefix the pipeline writes with.

dodil data object destination update

dodil data object destination update [pipeline-id] -b BUCKET \
  [--target-prefix PREFIX] [--target-bucket BUCKET] \
  [--excluded-prefix PREFIX] [-d DESC]

Edits the bound destination in place — only the flags you pass change; the rest are left alone. Per-facet validation applies exactly as on create, so a blank --target-prefix is rejected here too — update cannot walk a destination into a state create would have refused. The destination’s facet is immutable: an object destination stays an object destination.

dodil data object destination delete

dodil data object destination delete [pipeline-id] -b BUCKET

Deletes the pipeline row (and its destination). This is wiring only — it does not delete the derived files already written under target_prefix; those are ordinary objects you remove yourself. Delete the ingest rule first, or use POST /:bucket/pipelines/_batch-delete (BatchDeleteArtifacts) to unwind rules → pipelines → destinations in dependency order.

RULE_ID=$(dodil data ingest list -b kb-prod -p "$PIPELINE_ID" -o json | jq -r '.rules[0].ruleId')
dodil data ingest delete "$RULE_ID" -b kb-prod
dodil data object destination delete "$PIPELINE_ID" -b kb-prod

See also

• Pipelines — API Reference → Pipelines — CreateObjectPipeline, ObjectConfig, and the shared pipeline CRUD
• dodil data vector collection — the vector facet creator, same shape
• dodil data ingest — bind the rule that makes the pipeline fire
• dodil data recipe — one-command provisioning incl. object pipelines
• Pipelines — Overview → Pipeline kinds — where the object kind sits