dr_run()

Checks the complete definition and dependency graph before acquiring data. Sources are acquired once, transformations run in order, and contract and quality failures block publication. Shared upstream products run once within the same execution. Without a target, the result retains its checked table; dr_collect() materializes lazy output when it is needed.

Usage

dr_run(pipeline, lake = NULL, ...)

Arguments

pipeline: Product to execute.
lake: Optional connected lake or lake configuration, overriding the product's target for this run. Prefer dr_set_target() in reusable definitions.
...: Execution options described above or provided by an adapter. For products, write = FALSE evaluates sources and quality through the same path while disabling target, catalog and evidence writes for all dependencies. It does not verify destination permissions, capacity or publication conflicts.

Value

For products, a run result containing status, timestamps, input and output descriptors, quality, metadata and lifecycle. On failure an error contains the same result in condition$result.

Details

Product execution options passed through ... include:

• data: a new delivery replacing the sole primary input while retaining its name, transformations and checks. If the primary input is a product, its single-primary-input chain is followed to the ordinary delivery, retaining every intermediate product and gate. Ambiguous branches require an explicit name through sources.
• sources: a named list of replacements using dr_set_sources() names. Use either data or sources. The original definition and unselected pinned results remain unchanged. Both options replace whole inputs, not individual rows; partition replacement requires an explicit target policy.
• execution: an optional dr_execution_config() value, overriding defaults stored by dr_product(execution = ). Engine defaults propagate through dependencies; explicit step choices win. Destination and layer defaults apply only to the root product. Untargeted dependencies stay in memory, and existing dependency targets are preserved. Stored defaults on nested products are not activated during dependency execution.
• stop_on_failure: defaults to TRUE. Set FALSE to receive failed or blocked run results for programmatic inspection.
• evidence: an optional directory for durable run records. Defaults to getOption("dataraft.evidence"); no evidence directory is required.
• cache: lake targets default to FALSE. TRUE reuses a matching current release and requires an explicit product code_version. Live reference quality checks cannot reuse cached releases.
• business_date and notify: optional lake publication context and an existing notification callback. A product with an output-port SLA requires business_date for publication; the successful delivery is evaluated against the deadline and recorded with run evidence.

Selecting a quality engine through execution defaults preserves the declared contract's fingerprint. Execution evidence separately records the resolved checking engine. An explicit product code version still identifies its execution choices; a changed business promise needs a new contract version.

Metrics and dbt project specifications also have execution methods; see dataraft.metrics::dr_measure() and dataraft.dbt::dr_dbt_build() for their operation-specific options/results. Managed dbt projects also accept sources, a named list of successful lake releases. Bindings are validated before the dbt command runs.

Examples

orders <- dr_product("orders") |>
  dr_add_source(data.frame(id = 1:2, amount = c(25, 75))) |>
  dr_add_quality(~ amount >= 0)
result <- dr_run(orders)
dr_collect(result)
dr_inspect(result)