Add custom parameters to Custom Expectations
Using custom parameters in your Custom Expectations can help you create powerful, business-specific validations and help you optimize your Great Expectations (GX) workflows. Custom parameters should be implemented when you have data dependencies that can’t or shouldn’t be hardcoded. The method of implementing custom parameters is specific to the Custom Expectation class being extended.
Implementation
All Custom Expectations include a
success_keys
attribute that is a tuple of
strings. The tuple items are the names of the
parameters which are available during the evaluation
of your Custom Expectation. For example, the
success_keys
attribute for the
ColumnPairMapExpectation appears similar to the
following example:
success_keys = (
"column_A",
"column_B",
"mostly",
)
The tuple in the example includes the two columns
being evaluated and the mostly
parameter.
These parameters are passed as a part of your
ExpectationConfiguration and are available to the
Expectation _validate
method.
Use case
In this use case, a
condition_value_keys
tuple and a
condition_domain_keys
tuple are added to
ColumnPairMapMetrics, MulticolumnMapMetrics, and
ColumnMapMetrics. The
condition_value_keys
tuple supplies the
arguments needed to compute your Metric, and the
condition_domain_keys
tuple defines the
domain on which the Metric operates.
All parameters being passed to a Metric for use in value or domain keys must also be passed as success_keys in the Expectation class.
This is how the tuples appear in the MulticolumnMapMetrics Metric:
condition_domain_keys = (
"batch_id",
"table",
"column_list",
"row_condition",
"condition_parser",
"ignore_row_if",
)
condition_value_keys = ("sum_total",)
ColumnAggregateMetrics, TableMetrics, and QueryMetrics can similarly define a value_keys tuple or a domain_keys tuple:
value_keys = ("column",)
domain_keys = ("query",)
After the attributes are added to the Expectation and the Metric, the custom parameters can be passed into and used within the individual Metric functions. For example, this is how it appears in the ColumnValuesBetween Metric:
classColumnValuesBetween(ColumnMapMetricProvider):
condition_metric_name = "column_values.between"
condition_value_keys = (
"min_value",
"max_value",
"strict_min",
"strict_max",
"parse_strings_as_datetimes",
"allow_cross_type_comparisons",
)
@column_condition_partial(engine=PandasExecutionEngine)
def_pandas(
cls,
column,
min_value=None,
max_value=None,
strict_min=None,
strict_max=None,
parse_strings_as_datetimes: bool = False,
allow_cross_type_comparisons=None,
**kwargs
):
To view the full code that you would use to pass custom parameters in a Custom Expectation, see expect_column_values_to_be_lat_lon_coordinates_in_range_of_given_point.py.
kwarg-based access
GX recommends using custom parameters to create
validations and optimize workflows. However, you can
also use kwarg
syntax to define Metrics
for your Expectations. An example
kwarg
implementation is provided in
expect_column_values_to_be_lat_lon_coordinates_in_range_of_given_point.py.
To use kwarg
syntax to define Metrics for
your Expectations, you need to set the
kwargs
with a value_keys tuple first.
Default parameters
The following table lists the default parameters that are available for each Expectation class.
Expectation class | Default parameters |
---|---|
BatchExpectation | See BatchExpectation |
ColumnAggregateExpectation | See ColumnAggregateExpectation |
ColumnMapExpectation | See ColumnMapExpectation |
RegexBasedColumnMapExpectation | See RegexBasedColumnMapExpectation |
SetBasedColumnMapExpectation | See SetBasedColumnMapExpectation |
ColumnPairMapExpectation | See ColumnPairMapExpectation |
MulticolumnMapExpectation | See MulticolumnMapExpectation |
QueryExpectation | See QueryExpectation |