The backfill docs say this about backfill runs that work on multiple partitions in one run:

> If your code uses any of the partition_key, asset_partition_key, asset_partition_key_for_output, or asset_partition_key_for_input context methods or properties, you'll need to update it to use methods or properties like asset_partitions_time_window, asset_partition_key_range, asset_partition_keys, asset_partitions_time_window_for_output, asset_partition_key_range_output, asset_partitions_time_window_for_input, or asset_partition_key_range_for_input instead.

That’s a lot of methods and properties. I am not sure which I need to check. What are the scenarios for when they are used? Are there others that aren’t listed? The vague language (“methods or properties _like_…_”_) is pretty ominous.

Hi Spencer. Definitely agree that there's room for improvements on the docs. Basically, assuming that you've previously structured your code with the assumption that each run targets only one partition, you're probably using

context.partition_key

to get the currently executing partition. The following other context methods do similar things: •

context.asset_partition_key

/

context.asset_partition_key_for_output

assume your run is executing on a single partition. Not sure why we have so many methods that do the same thing--definitely room for consolidation. If you instead want to enable executing a run across multiple partitions, you'll need to replace

context.partition_key

with

context.asset_partition_key_range

. • The other methods

asset_partitions_time_window

,

asset_partition_keys

are pretty much just convenience methods that transform the key range into formats that might be more useful for you. The main methods are the ones I mentioned above, you probably don't need to worry about the input methods unless if you have interesting partition mapping relationships that are not 1-to-1.

Got it, super helpful! Thanks Claire