The assets to materialize.Unless you’re using deps or non_argument_deps, you must include all upstream assets. This is because upstream asset definitions contain information needed to load their contents when materializing downstream assets.Use the selection argument to distinguish between assets you want to materialize and assets present only for loading.
from dagster import asset@assetdef upstream_asset(): return [1, 2, 3]@assetdef downstream_asset(upstream_asset): return sum(upstream_asset)# Must include both assetsmaterialize([upstream_asset, downstream_asset])
Resources needed for execution. Can provide resource instances directly or resource definitions.If provided resources conflict with resources directly on assets, an error is thrown.
A sequence of AssetsDefinition or SourceAsset objects
An AssetSelection object
# Materialize only downstream_asset, loading from upstream_assetmaterialize( [upstream_asset, downstream_asset], selection=[downstream_asset])# Using selection syntaxmaterialize( [asset1, asset2, asset3], selection="asset1+" # asset1 and its downstream dependencies)
output_for_node(node_name) - Retrieve output value for a specific node
asset_materializations_for_node(node_name) - Get materialization events
all_events - All events that occurred during execution
run_id - The unique identifier for this run
result = materialize([my_asset])# Check successassert result.success# Get output valueoutput_value = result.output_for_node("my_asset")# Get materialization metadatamaterializations = result.asset_materializations_for_node("my_asset")for mat in materializations: print(mat.metadata)
from dagster import asset, materialize@assetdef raw_data(): return [1, 2, 3, 4, 5]@assetdef processed_data(raw_data): return [x * 2 for x in raw_data]@assetdef aggregated_data(processed_data): return sum(processed_data)# Materialize only processed_data and aggregated_data# raw_data is included for loading but not materializedresult = materialize( [raw_data, processed_data, aggregated_data], selection=[processed_data, aggregated_data])
Use materialize to test assets locally before deploying:
from dagster import asset, materialize@assetdef my_asset(): # Asset logic return dataif __name__ == "__main__": # Test locally result = materialize([my_asset]) print(f"Success: {result.success}")
Unit Testing
Test asset logic in unit tests:
import pytestfrom dagster import asset, materialize@assetdef data_processor(context): # Process data return processed_datadef test_data_processor(): result = materialize([data_processor]) assert result.success output = result.output_for_node("data_processor") assert len(output) > 0
Interactive Development
Quickly iterate on asset logic in notebooks or scripts:
from dagster import asset, materialize@assetdef experimental_feature(): # Try new logic return new_approach()# Run immediately to see resultsresult = materialize([experimental_feature])
materialize persists assets to the configured IO manager (filesystem by default), while materialize_to_memory keeps everything in memory.Use materialize when:
Parameters are identical to materialize, with one key difference:
Important: materialize_to_memory will explicitly use mem_io_manager for all required IO manager keys. If any IO managers are provided via the resources argument, a DagsterInvariantViolationError is thrown.