The Data Query toODataString function currently treats GUIDs as strings, as there is no built-in JavaScript mechanic to distinguish between the two types.
The toODataString function should return a proper formatted OData query string, and a possible solution could be to have a boolean property on the FilterDescriptor to indicate the filter field is to be treated as a GUID, similar to the ignoreCase property that exists now.
Hi,
I've just started to use the process method of the Data query library and there is no way of filtering a property that is an array, even as simple array such as Array<string>.
ie:
interface Person {
id: string;
name: string;
categoryIds: Array<string>
}
I have many instances where I have properties that are arrays of string ids, so was hoping to use this utility to help filter the data.
Whilst adding an additional operator such as includes would help, how about adding the ability to register a custom operators?
Thanks,
Anthony.
Hi Team,
Currently, the CompositeFilterDescriptor supports the following two logical operators - and and or.
I would like to request the addition of a none logical operator.
Please export the operatorsMap from Data Query's filter-no-eval.js.
If exporting the operators map is not an option, consider introducing an enum which defines the operators as constants:
export enum Operators {
contains = 'contains',
doesnotcontain = 'doesnotcontain',
doesnotendwith = 'doesnotendwith',
doesnotstartwith = 'doesnotstartwith',
endswith = 'endswith',
eq = 'eq',
gt = 'gt',
gte = 'gte',
isempty = 'isempty',
isnotempty = 'isnotempty',
isnotnull = 'isnotnull',
isnull = 'isnull',
lt = 'lt',
lte = 'lte',
neq = 'neq',
startswith = 'startswith'
}
Current behavior
Currently, toODataString() does not fix filter operators like process() does for the grid data.
Our team is using OData to do server side filtering on kendo grids.
When given the filter operator 'equals', the current implementation of the code will error out when trying to create a serialized query string for OData operations. That is because it is actually trying to look for the operator 'eq' to create the string.
This is because the toODataString does use the operatorMap that is in filter.operator.js.
process(), used for client-side paging however does. And will fix the value before applying the operation.
Expected behavior
What I would expect toODataString to do. Is make use of the same correcting that process() does.
So my filters in the State object can use either 'equals' or 'eq'.
This stumped me for a bit, and would be an easy fix. I think changing this would save people some time. And make the functions used for server-side and client-side paging, uniform.
Minimal reproduction of the problem with instructions
https://stackblitz.com/edit/angular-a8rdk3
In this example, you can see changing 'equals' to 'eq' will make it stop erroring.
TLDR -> toODataString() doesn't understand 'equals', like process() does.