Transform results

Is your feature request related to a problem? Please describe.

When parsing an excel row an object value can be int, double or string.

A transform validator can determine whether the object is of an allowed type, and if so if it is truly an integer.

Once that processing is done ValidationResult is returned and if the object is valid, the transform needs to be performed again, since the ValidationResult does not contain the result.

Describe the solution you’d like

TTransformed? TransformedResult { get; } could be added to ValidationResult or a type that derives from it such as TransformedValidationResult<T>

Describe alternatives you’ve considered

The alternative to avoiding the transformation is to generate a list of ValidationFailures outside the FluentValidation library.

Additional Context

No response

[JeremySkinner]

I don’t think setting context.RootContextData helps, since it is not available in the ValidationResult instance.

It doesn’t need to be on the result - if you instantiate the context directly before calling Validate, you can access the context again after validation has been completed.

It would seem to me that after a successful validation, the user is likely to need the int again.

If the user needs the int outside of the validator, then it should be parsed/transformed outside of the validator, eg through a surrogate property (or some other solution)

[virzak]

Seems to me that this should be a common issue using transformations. In the documentation example, the string is converted to int. It would seem to me that after a successful validation, the user is likely to need the int again.

public record MyObject (string SomeStringProperty);

public class TransformValidator : AbstractValidator<MyObject>
{
    public TransformValidator()
    {
        Transform(x => x.SomeStringProperty, StringToNullableInt).GreaterThan(10);
    }
    public static int? StringToNullableInt(string value)
      => int.TryParse(value, out int val) ? val : null;
}

class Caller
{
    void Validate()
    {
        var myObject = new MyObject("abc");

        var result = new TransformValidator().Validate(myObject);

        if (result.IsValid)
        {
            var myInt = TransformValidator.StringToNullableInt(myObject.SomeStringProperty)!.Value;
        }
    }
}

So int.TryParse is being called twice to do the exact same work. The more expensive transformations and the more instances to validate (such as a huge csv / excel spreadsheet) the slower it will be.

I don’t think setting context.RootContextData helps, since it is not available in the ValidationResult instance.

It is totally possible to have a solution where the string is only parsed once, without using the FluentValidation library, but I was just thinking it could be a common problem.