Hey all, I have an asset define like this. ``` @a...
# ask-community
o
Hey all, I have an asset define like this.
Copy code
@asset(
    config_schema={
        "limit": int,
        "cohort_table": str,
        "database": str
    },
    required_resource_keys={'aws'},
    # ins={
    #     "cohort": AssetIn(
    #         input_manager_key="pandas_df_manager",
    #         key=AssetKey(('qld_health', 'qld_health_simple_cohort'))
    #     )   
    # },
    non_argument_deps={
        AssetKey(('qld_health', 'qld_health_simple_cohort'))
    }

)
def cohort(context,
    # cohort
):
    pass
when setting
non_argument_deps
to the source asset everything works as expected and the UI shows the correct lineage. however when trying to supply an argument asset using the ins and the same AssetKey I get
Input asset '["qld_health", "qld_health_simple_cohort"]' for asset '["cohort"]' is not produced by any of the provided asset ops and is not one of the provided sources
any ideas what I'm missing here?
dagster bot resolve to issue 1
o
seems related to the question I had the other day. Perhaps it’ll help - https://dagster.slack.com/archives/C01U954MEER/p1659136358342089
o
Thanks! I don't think these are related though, my issue occurs when trying to load the repository, before I get a chance to use materialise.
o
hi @Oliver! Do you have a SourceAsset defined for qld_health_simple_cohort? This is required for the AssetIn case because Dagster needs to know how to load that input value (specifically, it needs an IOManager key to use). For non_argument_deps, no input value is loaded, so it's ok to not have a SourceAsset defined, which is why the behavior differs here.
something as simple as adding
SourceAsset(key=('qld_health', 'qld_health_simple_cohort'))
to your repository should do the trick, I would think (this would use the default io manager)
o
ah ok, yup loads when I add that. thanks I did set the
input_manager_key
in the AssetIn definition, whats the difference between setting the io_manager in these two locations?
o
honestly that's a good point — it might be worth relaxing that rule when an input manager is supplied
🌈 1