Topic
Add support for transformation and normalization of specific fields
Relevant information
The entry point for custom transformers in the CDK is
@transformer.registerCustomTransform
def transform_function(original_value: Any, field_schema: dict[str, Any]) -> Any:
...Only the schema for, and value of, fields are passed to this function, making it unpleasant to apply transformations to specific fields coming out of records. It would be useful to be able to see the actual field name in addition to its value and schema.
Practically, I think that would just be a matter of passing k as well as instance[k] to the transformer function here; resolution for list items could potentially pass the name of the parent field.
Alternatively, we could pass field_path where field_path is the location of the field from the root JSON (so the path for field B nested in object A would be ["A", "B"], with some analogous for list items). Whatever the case, I think it would make sense to match the same JSON-path-like list supported by primary_key and the others.
It would also be neat to support whole-record transformations for operations that require knowledge/the context of the other fields in a record; so not field-by-field transformations, but also record-by-record ones. The latter could be somewhat supported by passing the entire record original instance to every transformer call, basically another original_record parameter to the fn to an extent, but would not enable the aggregation or deletion of fields from the original record (which is a logical desire).
Topic
Add support for transformation and normalization of specific fields
Relevant information
The entry point for custom transformers in the CDK is
Only the schema for, and value of, fields are passed to this function, making it unpleasant to apply transformations to specific fields coming out of records. It would be useful to be able to see the actual field name in addition to its value and schema.
Practically, I think that would just be a matter of passing
kas well asinstance[k]to the transformer function here; resolution forlistitems could potentially pass the name of the parent field.Alternatively, we could pass
field_pathwherefield_pathis the location of the field from the root JSON (so the path for fieldBnested in objectAwould be["A", "B"], with some analogous for list items). Whatever the case, I think it would make sense to match the same JSON-path-like list supported byprimary_keyand the others.It would also be neat to support whole-record transformations for operations that require knowledge/the context of the other fields in a record; so not field-by-field transformations, but also record-by-record ones. The latter could be somewhat supported by passing the entire record original instance to every transformer call, basically another
original_recordparameter to the fn to an extent, but would not enable the aggregation or deletion of fields from the original record (which is a logical desire).