SDA docs fixes (#6905)

dagster-io · Mar 14, 2022 · 07c3887 · 07c3887 · vercel · Mar 14, 2022
1 parent 28d74c3
commit 07c3887
Show file tree

Hide file tree

Showing 7 changed files with 16 additions and 4 deletions.
diff --git a/docs/content/api/modules.json b/docs/content/api/modules.json
diff --git a/docs/content/api/searchindex.json b/docs/content/api/searchindex.json
diff --git a/docs/content/api/sections.json b/docs/content/api/sections.json
diff --git a/docs/content/concepts.mdx b/docs/content/concepts.mdx
@@ -76,7 +76,7 @@ Each page in this section contains:
     define them and their convenient capabilities like partitioning and
     backfilling.
   </LinkGridItem>
-  <LinkGridItem title="Assets" href="/concepts/assets/asset-materializations">
+  <LinkGridItem title="Assets" href="/concepts/assets/software-defined-assets">
     Assets are data objects that you produce during a run. This section walks
     you through how to inform Dagster about these assets so that they can be
     tracked over time.

diff --git a/docs/content/concepts/assets/asset-materializations.mdx b/docs/content/concepts/assets/asset-materializations.mdx
@@ -5,6 +5,8 @@ description: Dagster provides functionality to record and track changes to exter
 
 # Asset Materializations
 
+[Software-defined assets](/concepts/assets/software-defined-assets) provide a declarative way to define what assets should exist and how to create them. But when it's not known what asset an op is going to materialize until the op runs, you can still create assets using <PyObject object="AssetMaterialization" /> events.
+
 "Asset" is Dagster's word for an entity, external to ops, that is mutated or created by an op. An asset might be a table in a database that an op appends to, an ML model in a model store that an op overwrites, or even a slack channel that an op writes messages to.
 
 Op outputs often correspond to assets. For example, an op might be responsible for recreating a table, and one of its outputs might be a dataframe containing the contents of that table.
@@ -330,3 +332,9 @@ src="/images/concepts/assets/asset-lineage.png"
 width={1607}
 height={1031}
 />
+
+## Software-defined assets vs. Asset Materializations
+
+When working with software-defined assets, the assets and their dependencies must be known at definition time. When you look at software-defined assets in Dagit, you can see exactly what assets are going to be materialized before any code runs.
+
+Asset Materializations, on the other hand, are logged at run time. When you run an op, you find out which assets were materialized while the op is running. This allows for some flexibility, like if you wanted to determine which assets should be materialized based on the output of a previous op.
diff --git a/docs/content/concepts/assets/software-defined-assets.mdx b/docs/content/concepts/assets/software-defined-assets.mdx
@@ -408,3 +408,7 @@ def my_asset(context):
     # fetches contents of an asset
     return context.resources.api.fetch_table("my_asset")
 ```
+
+## Further Reading
+
+Interested in learning more about software-defined assets and working through a more complex example? Check out our [guide on software-defined assets](/guides/dagster/software-defined-assets) and our [example project](https://github.com/dagster-io/dagster/tree/master/examples/modern_data_stack_assets) that integrates software-defined assets with other Modern Data Stack tools.
diff --git a/docs/next/public/objects.inv b/docs/next/public/objects.inv