Hi, the list of removed APIs in the migration guide for version 1.0 states that

SolidExecutionContext

was removed. I'm still getting

<class 'dagster._core.execution.context.compute.SolidExecutionContext'>

as

type(context)

on version 1.0.3

It's removed from the public API, but still there internally although we intend to remove it soon -

OpExecutionContext

extends it. Is it causing you trouble?

I see. No, it's causing no trouble. I only thought that it was completely removed in 1.0 and wanted to point it out in case it was left unintentionally. While I'm at it, I have another question on my mind. What's your approach on the combination of assets and lazy evaluation? Say I define several subsequent assets returning Spark or Snowpark DataFrames but I only want to collect the last (downstream) one, would I use an in-memory IO manager to materialize the intermediate results, and a separate IO manager for the final asset that collects it? And I assume I could only run it in-process?

Say I define several subsequent assets returning Spark or Snowpark DataFrames but I only want to collect the last (downstream) one, would I use an in-memory IO manager to materialize the intermediate results, and a separate IO manager for the final asset that collects it? And I assume I could only run it in-process?

That's exactly right

Perfect. Assume that after collecting the DataFrame, I want to use this asset as an upstream for further downstream assets/ops which could be executed multi-process. Is it possible to define which executor to use on an asset or on an asset group level within one materialization run (i.e. for different assets different executors are used)?

currently, each run only has a single executor. you could define different jobs with different executors that each process different subsets of assets

Okay thanks I think that's what I'll do