Enable custom query validato into SelectExpandQueryValidator - #800
Conversation
| /// <param name="validationSettings">The validation settings.</param> | ||
| void Validate(SelectExpandQueryOption selectExpandQueryOption, ODataValidationSettings validationSettings); | ||
|
|
||
| // Task ValidateAsync(SelectExpandClause selectExpandClause, ODataValidationSettings validationSettings); |
There was a problem hiding this comment.
What's the deal with the commented code? Shouldn't it be removed?
There was a problem hiding this comment.
Oh, Yes. Forgot it. Will update it.
| remainDepth = maxDepth; | ||
| } | ||
|
|
||
| //if (expandConfiguration.MaxDepth > 0 && currentDepth >= expandConfiguration.MaxDepth) |
There was a problem hiding this comment.
Should this commented out code be removed instead?
| /// <summary> | ||
| /// Validates $select. For example, ~/Customers?$select=Prop($select=SubProp;$top=2) | ||
| /// </summary> | ||
| /// <param name="pathSelectItem"></param> |
There was a problem hiding this comment.
Supply the parameter description
| ValidateSearch(pathSelectItem.SearchOption, subValidatorContext); | ||
|
|
||
| // Validate the nested $compute within $select | ||
| ValidateCompute(pathSelectItem.ComputeOption, subValidatorContext); |
There was a problem hiding this comment.
I assume it's not valid to have $levels and $apply nested in a $select expression?
| /// </summary> | ||
| /// <param name="filterClause">The nested $filter clause.</param> | ||
| /// <param name="validatorContext">The validator context.</param> | ||
| protected virtual void ValidateFilter(FilterClause filterClause, SelectExpandValidatorContext validatorContext) |
There was a problem hiding this comment.
For this method and the related ones, would it have been better to named them ValidateNestedXXX?
There was a problem hiding this comment.
I original thought we don't need 'nested' since they are 'protected virtual' within SelectExpandValidator.
But, I am ok to rename them.
There was a problem hiding this comment.
Given your explanation it would have been okay to retain them as they were...
There was a problem hiding this comment.
#Resolved. Never mind, I updated them.
| OrderByModelLimitationsValidator orderByQueryValidator = | ||
| new OrderByModelLimitationsValidator(validatorContext.Context, validatorContext.Context.DefaultQuerySettings.EnableOrderBy); | ||
|
|
||
| orderByQueryValidator.TryValidate(validatorContext.Property, validatorContext.StructuredType, orderByClause, false); |
There was a problem hiding this comment.
Does TryValidate return a boolean value of true/false and should we be checking the return value?
There was a problem hiding this comment.
That's the old codes/existing codes that I will refactor later (next PR).
| protected virtual void ValidateOrderby(OrderByClause orderByClause, SelectExpandValidatorContext validatorContext) | ||
| { | ||
| if (filterClause != null) | ||
| if (orderByClause != null) |
There was a problem hiding this comment.
Just to observe that in some methods, you're doing:
if (xxxOption == null)
{
return;
}
// Validation logic hereHere and in some other methods you're nesting the validation logic within the if block...
There was a problem hiding this comment.
It depends on the "number of codes line". #won't fix.
…ryValidator.cs Co-authored-by: John Gathogo <john.gathogo@microsoft.com>
| _structuredType = filterQueryOption.Context.TargetStructuredType; | ||
| } | ||
|
|
||
| _property = filterQueryOption.Context.TargetProperty; |
There was a problem hiding this comment.
I don't understand this change. Why was the if statement there in the first place?
There was a problem hiding this comment.
I think it's safe to check.
Actually, in the ODataQueryContext, we have the Path null check already.
Now, I added an internal constructor to set the TargetStructuredType and property, so, we should remove the null check here.
|
|
||
| /// <summary> | ||
| /// The remaining depth on property. | ||
| /// It's weird logic in current implementation. Need to improve it later. |
There was a problem hiding this comment.
What implementation does this comment refer to? Why is it weird? If it needs to be implemented late, consider creating an issue to track it.
There was a problem hiding this comment.
It's weird because the 'RemainingDepth' is working with the query setting configuration on the property. I can't understand such logic.
Maybe it's correct, but I do not fully understand this.
Let me update the description.
| ValidationSettings = this.ValidationSettings, | ||
| Property = this.Property, | ||
| StructuredType = this.StructuredType, | ||
| RemainingDepth = this.RemainingDepth, |
There was a problem hiding this comment.
Is RemainingDepth property value set by the customer or by the framework? At which point is it calculated?
There was a problem hiding this comment.
In the SelectExpandQueryValidator.cs at line 192 at SelectExpandQueryValidator.cs
It's calculated at Line 170 - 176.
The codes read the query setting on property (Model query setting). Model query setting is something
public class Customer
{
[Expand(MaxDepth=3)]
public Order MyOrder {get;set;}
}
issue #767
Refactor SelectExpandQueryValidator by: