[components] Remove translator terminology from SlingReplicationCollectionComponent

[OwenKephart]

Summary & Motivation

The translator language was fairly confusing. Went through some iterations but arrived in a place where the translation layer can be overridden in yaml using the asset_attributes field. This field will have the domain-specific object in scope, meaning you can use that to set attributes if desired.

At the same time, this leaves open the ability for users to specify a python-based translator to override the default one.

Made the following changes:

1. Because we want to use the key asset_attributes to replace translator, this conflicts with the global asset_attributes field, so I renamed this to be asset_transforms. This gives a better sense of the fact that you're doing specific operations over all assets (imo)
2. Removed the weird subclassing stuff with the existing asset transforms -- this was only necessary in a world where merge / replace supported different argument sets, but this is no longer the case so the extra complexity was unnecessary
3. Added a generic wrapper layer to make it easier to create these sorts of translator wrappers that incorporate both a base translator as well as jinja templating

How I Tested These Changes

Changelog

NOCHANGELOG

[OwenKephart]

• [components][fix] Fix issue with additional scope determination #27043
• [components][docs] Schema viewer #26978
• [components][refactor] Refactor schema resolution files #27040
• [components] DbtComponent QoL improvements #26955
• [components][rfc] rendering -> resolution #26953
• [components] Allow specification of rendering scope #26952
• [components] Update translator handling in DbtProjectComponent #26946
• [components] Remove translator terminology from SlingReplicationCollectionComponent #26927 👈 (View in Graphite)
• [components] Convert params schema from classvar to classmethod #26925
• master

This stack of pull requests is managed by Graphite. Learn more about stacking.

[schrockn]

What would the update to the README (in Notion) look like?

e.g. right now we have

type: dagster_components.dbt_project

params:
  dbt:
    project_dir: ../../../dbt/jdbt
  translator:
    key: "target/main/{{ node.name }}"

at one point.

What does it look like in this new regime?

[OwenKephart]

@schrockn

Updated this such that this would end up looking like:

type: dagster_components.dbt_project

params:
  dbt:
    project_dir: ../../../dbt/jdbt
  asset_attributes:
    key: "target/main/{{ node.name }}"

[schrockn]

Should it just be "transforms" since it might select asset checks only?

[OwenKephart]

sounds good to me

updated to transforms!

[schrockn]

Why is it temporary? What is the "permanent" fix?

[schrockn]

This does strike me as wacky and something that could end up living for a long time.

I would expect a more "normal" adapter class per component that wraps as instance of the original.

The "heavy lifiting" in this class is _get_rendered_attribute which could be called as a standalone function

@dataclass
class RenderingInfo:
  obj_name: str
  asset_attributes: AssetAttributesModel,
  value_renderer: TemplatedValueRenderer

  def get_rendered_attr(...): ...

   def get_asset_key(self, obj, default) -> AssetKey:
     return self.get_rendered_attr("key", obj, default)

class RenderingSlingTranslator(SlingTranslator)
   rendering_info: RenderingInfo
   wrapped_translator: SlingTranslator

   def get_asset_key(self, obj) -> AssetKey:
    return self.rendering_info.get_asset_key(obj, self.wrapper_translator) 

Something like this is a little more code but I think much more obvious

[schrockn]

dynamically created class seems too magical

added explanation, refactored the implementation to be "ready for the future"

[OwenKephart]

Merge activity

• Jan 10, 8:20 PM EST: A user started a stack merge that includes this pull request via Graphite.
• Jan 10, 8:25 PM EST: Graphite rebased this pull request as part of a merge.
• Jan 10, 8:26 PM EST: A user merged this pull request with Graphite.