Right now, when calling the ToDataSourceResult extension method on IQueryable object, the DB is queried using the given filters for example from a DataSourceRequest object. However, if I want to apply complex queries based on those filters, this is not possible unless rewriting the existing extension method to return an IQueryable.
Proposal Example API
var dataSourceRequest = new DataSourceRequest();
DataSourceResultWithQuery dataSourceResultWithQuery = query.ToDataSourceResultWithQuery(dataSourceRequest);
public class DataSourceResultWithQuery : DataSourceResult
{
[JsonIgnore]
public IQueryable query { get; set; }
}
Is it possible for this to be added as an extension method? I am currently doing this using a custom class that parses the dataSourceRequest class and returning the IQueryable, but it would be nice if this was an included extension method.
Thank you.
Hello John,
Thank you for the additional information. I think now I understand the use case better.
However, such an extension method that returns IQueryable seems to deviate from the general purpose of the ToDataSourceResult method. This method is primarily designed to prepare data in a suitable format for the Telerik components (like Grid), and when it returns an IQueryable, its intended functionality differs from generating a DataSourceResult.
If custom operations are required, it is recommended to follow your current approach of handling those operations with LINQ methods and using the DataSourceRequest parameters if needed.
Considering these factors, I will proceed by setting the status of this item to "Declined." This decision is aimed at upholding a cleaner API that consistently returns valid DataSourceResult objects, which avoids confusion and prevents the introduction of extension methods that return something different.
We genuinely appreciate your input and understanding as we strive to provide the best possible solutions for our users. If you have any further questions or concerns, please don't hesitate to let me know.
Regards,
Yanislav
Progress Telerik
Hello Yanislav,
Regarding your requirement, please correct me if I misunderstood you but based on the description I understand it is about introducing an extension method that applies the data source request and returns an IQueryable that you can additionally modify. Is that correct?
You are correct. The reason I might want the IQueryable exposed after the data source result is provided is to handle complex linq queries after the result is returned.
The DataSourceRequest provides the IList<AggregateDescriptor> property for aggregate functions such as sum, count, average, min, and max.
But what if I sort and apply any numerous amounts of filters and then want to apply a complex linq query that doesn't fall into one of the supported aggregate functions?
For example, suppose I have a telerik grid that uses the following Country model (this is a fake example):
}
Using the example above, each country has a population and any number of religions which may or may not overlap with each country.
Using the Grid Aggregates function in a Blazor Telerik Grid I could get the sum of the country population using GridAggregates:
<GridAggregates>
<GridAggregate Field=@nameof(CountryModel.Population) Aggregate="@GridAggregateType.Sum" />
</GridAggregates
This would give me the sum population of all countries after the filters have been applied. For example I could filter out any countries starting with A.
What if I want to apply the following complex query after the filters have been applied.
The AggregateDescriptors are not going to allow for complex queries after filtering has been applied.
Since the method works with IQueryable, may I ask if is there a reason to not first apply the required custom operations and then call the ToDataSourceResult?
If I apply the custom IQueryable operation before ToDataSourceResult is applied I'm not going to get the results I want with the applied filters.
Additionally, if I understand the requirement correctly, you are looking for an extension that allows you to exclude the paging operation.
No, I was just stating that if the IQueryable is provided back to after calling ToDataSourceResult, the provided IQueryable should not include paging. In the existing source code for the QueryableExtensions static class under the CreateDataSourceResult method their is a variable called notPagedData. This is the IQueryable value that should be passed back.
If that's the case, you can try to manually apply the necessary operations.
By iterating through the DataSourceRequest descriptors and using LINQ methods, you will have full control over what is applied to the query.
This is what I am doing now. I cloned the QueryableExtensions method and modified it to return the IQueryable. It would be nice for myself—and others—if this was included out of the box so I don't have to manage breaking changes. It could also help others handle complex linq queries where the AggregateDescriptors will not suffice.
Let me know if this makes sense. If not, I could expound on it further.
John
Hello John,
Generally, the purpose of the ToDataSourceResult method is to apply data source request properties like filtering, sorting, and paging to an IEnumerable or IQueryable collection and return a DataSourceResult.
Regarding your requirement, please correct me if I misunderstood you but based on the description I understand it is about introducing an extension method that applies the data source request and returns an IQueryable that you can additionally modify. Is that correct?
Since the method works with IQueryable, may I ask if is there a reason to not first apply the required custom operations and then call the ToDataSourceResult?
var query = Data.Where(x => x.Name.Contains("test"));
var result = query.ToDataSourceResult(args.Request);
Additionally, if I understand the requirement correctly, you are looking for an extension that allows you to exclude the paging operation. If that's the case, you can try to manually apply the necessary operations.
By iterating through the DataSourceRequest descriptors and using LINQ methods, you will have full control over what is applied to the query.
Please inform me if these approaches align with your requirements, or if there are any additional use cases that we may not have considered.
Regards,
Yanislav
Progress Telerik