Skip to main content

:::note Generated reference Generated from honeyframeapi 0.1.8 — do not edit by hand. :::

honeyframeapi.recipe

Recipe handle — inspect a flow recipe and build its output.

On a dbt-engine project a recipe's output is a dbt model, so running a recipe means a targeted dbt build of that model:

r = project.get_recipe("int_orders_unioned")
r.get_metadata()                 # type, inputs, steps, version
r.runs(limit=5)                  # recent executions
run = r.build(downstream=True)   # dbt run --select int_orders_unioned+

For authoring prepare recipes from code, use Recipe.save_prepare_steps (POST /api/flow/recipes/save-prepare).

class Recipe​

Recipe.recipe_id​

property

recipe_id: Optional[int]

Recipe.get_metadata()​

get_metadata() -> dict

Recipe metadata: id, recipe_type, inputs, steps, version.

Recipe.runs()​

runs(*, limit: int = 10) -> list[dict]

Recent executions of this recipe.

Recipe.engine_status()​

engine_status() -> dict

Per-recipe engine status — what the UI's recipe-engine picker shows.

The two engines are sql (NativeSqlEngine, in-database pushdown) and dbt; selectability derives from real checks (a SQL-shaped recipe whose stored steps compile / has inline SQL for sql; the dbt binary present for dbt). Returns {selected: {type, label}, pinned, default: {type, label}, engines: [{type, label, description, isSelectable, statusWarnLevel, statusMessage?}]}. Change it with Project.change_recipe_engines.

Recipe.save_prepare_steps()​

save_prepare_steps(*, source: str, steps: list, materialized: str = 'table', target_schema: Optional[str] = None, file_path: Optional[str] = None, source_columns: Optional[list] = None, expected_version: Optional[int] = None) -> dict

Author/overwrite a prepare recipe (steps → SQL → dbt file → DB).

Recipe.save()​

save(*, recipe_type: str, steps: list, inputs: Optional[list] = None, output_datasets: Optional[list] = None, inline_code: Optional[str] = None, expected_version: Optional[int] = None) -> dict

Write a recipe row of any type via POST /api/flow/save-recipe-steps.

The full-control authoring path. recipe_type ∈ prepare | python | sql_query | sql_script | split | … ; steps is the recipe's JSONB config in the Flow Builder's shape for that type (prepare steps are validated server-side). For sql_script pass the multi-statement script as inline_code. Pass expected_version (from get_metadata) for optimistic-locking; a stale value 409s.

For the common single-source prepare case prefer save_prepare_steps, which also generates the dbt SQL + file.

Recipe.set_sql()​

set_sql(inline_code: str, *, expected_version: Optional[int] = None) -> dict

Land runnable SQL on this recipe (native-engine orgs only).

PUT /api/flow/recipes/{id}/sql. save can only compile inline_code for recipe_type='prepare'; every other SQL-shaped type (sql, join, groupby, window, distinct, …) is stored with inline_code = NULL and then fails Project.build_native with "has empty inline_code". This is the write that fills it in.

{{ ref('model') }} / {{ source('schema','table') }} are resolved server-side against the project's dataset registry (and {{ config(...) }} is stripped); the write is REFUSED with 400 if any {{ survives, so half-resolved Jinja can never reach the warehouse. Pass expected_version (from get_metadata) for optimistic locking — a stale value 409s. A dbt-engine org gets 409: author the model file via project.dbt instead.

Returns {ok, recipe_id, model_name, recipe_type, target, version, inline_code} — inline_code being the RESOLVED SQL as stored.

Recipe.build()​

build(*, downstream: bool = False, upstream: bool = False, wait: bool = False, timeout: float = 1800.0, poll_interval: float = 5.0) -> dict

Build this recipe's dbt model via the pipeline (dbt run --select).

downstream/upstream add the + selectors. Returns the trigger response at once; with wait=True, blocks until the triggered run finishes and returns that run (see Project.run_dbt).

Verified against honeyframeapi 0.1.8.