Is your feature request related to a problem? Please describe.
In 11.1, there are a number of obsolete warnings for using the HotChocolate.Types.Filters and HotChocolate.Types.Sorting namespace, that suggest moving to the new HotChocolate.Data namespace.
The previous versions allowed a fluent-style syntax to explicitly set which filters/sorting operations to allow, but the new namespace allows all supported types by default.
E.g. this was the previous syntax allowed for this:
descriptor.Filter(t => t.Amount)
.BindFiltersExplicitly()
.AllowGreaterThanOrEquals()
.And().AllowLowerThanOrEquals();which is not supported.
As Pascal has let me know, this can be worked around by creating a ComparableOperationFilterInputType for each type that includes the filters that you want, but for porting mid-large projects, this will be quite a large task to move from 10.x to 11.x
Describe the solution you'd like
Support for a fluent type syntax on a per-field level would be great.
This could be the same structure ported over from 10.x, or from the examples Pascal sent, maybe it is easier to do this:
descriptor.Field(t => t.Amount)
.AddOperation(DefaultFilterOperations.GreaterThanOrEquals)
.MakeNullable();
descriptor.Field(t => t.Amount)
.AddOperation(DefaultFilterOperations.LowerThanOrEquals)
.MakeNullable();
descriptor.AllowAnd(false).AllowOr(false);Describe alternatives you've considered
- Opening up the fields to "all filters" instead of binding explicitly
- Creating ComparableOperationFilterInputType per operation set i want to allow
Additional context
I appreciate all the work the team has put in!
Is your feature request related to a problem? Please describe.
In 11.1, there are a number of obsolete warnings for using the HotChocolate.Types.Filters and HotChocolate.Types.Sorting namespace, that suggest moving to the new HotChocolate.Data namespace.
The previous versions allowed a fluent-style syntax to explicitly set which filters/sorting operations to allow, but the new namespace allows all supported types by default.
E.g. this was the previous syntax allowed for this:
which is not supported.
As Pascal has let me know, this can be worked around by creating a ComparableOperationFilterInputType for each type that includes the filters that you want, but for porting mid-large projects, this will be quite a large task to move from 10.x to 11.x
Describe the solution you'd like
Support for a fluent type syntax on a per-field level would be great.
This could be the same structure ported over from 10.x, or from the examples Pascal sent, maybe it is easier to do this:
Describe alternatives you've considered
Additional context
I appreciate all the work the team has put in!