From 9b48c249c10926bcdb717ecf85ffae8ca0a9c885 Mon Sep 17 00:00:00 2001 From: colton Date: Fri, 20 Dec 2024 13:54:48 -0500 Subject: [PATCH] Update docs/docs-beta/docs/tutorial/multi-asset-integration.md Co-authored-by: Nikki Everett --- docs/docs-beta/docs/tutorial/multi-asset-integration.md | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/docs/docs-beta/docs/tutorial/multi-asset-integration.md b/docs/docs-beta/docs/tutorial/multi-asset-integration.md index e0f3cb99f8a03..ea776f1e52e96 100644 --- a/docs/docs-beta/docs/tutorial/multi-asset-integration.md +++ b/docs/docs-beta/docs/tutorial/multi-asset-integration.md @@ -185,7 +185,11 @@ def my_assets(replication_resource: ReplicationProject): At the end of [Step 2](#step-2-implementation), we mentioned that end users were unable to customize asset attributes, like the asset key, generated by our decorator. Translator classes are the recommended way of defining this logic, and they provide users with the option to override the default methods used to convert a concept from your tool (for example, a table name) to the corresponding concept in Dagster (for example, asset key). -To start, we will define a translator method to map the table specification to a Dagster asset key. **Note**: in a real world integration you will want to define methods for all common attributes like dependencies, group names, and metadata. +To start, we will define a translator method to map the table specification to a Dagster asset key. + +:::note +In a real world integration, you will want to define methods for all common attributes like dependencies, group names, and metadata. +::: ```python from dagster import AssetKey, _check as check