JohnGalt1717
commented
4 years ago I was sort of able to address this by inheriting from the odata language definition and removing the default Datetime items and inserting these (appending didn't work because the string regex matches first that way)
protected override IEnumerable<GrammerDefinition> TypeDefinitions()
{
var defs = new List<GrammerDefinition>(base.TypeDefinitions());
defs.RemoveAll(d => d.Name == "DATETIMEOFFSET" || d.Name == "DATETIME");
defs.InsertRange(0, new[] {
new OperandDefinition(
name: "DATETIMEOFFSET",
regex: @"\d{4}-\d{1,2}-\d{1,2}T\d{1,2}:\d{1,2}:\d{1,2}\.\d{1,3}Z",
expressionBuilder: x => Expression.Constant(DateTimeOffset.Parse(x))
),
new OperandDefinition(
name: "DATETIME",
regex: @"\d{4}-\d{1,2}-\d{1,2}T\d{1,2}:\d{1,2}:\d{1,2}\.\d{1,3}Z",
expressionBuilder: x => Expression.Constant(DateTime.Parse(x))
)
});
return defs;
}
However, this gives me a error in .NET Core 3.1 EF that it can't interpret the Query, so I don't know what I'm doing wrong.
Wondering if it's that DATETIME would never be called there. Need to be able to make this more contextual so that it applies the right one for the right type of the field itself, not just the regex.
alex-davies
bookwood1977
Right now filters like this: CreatedOn ge 2019-10-01T00:00:00.000Z
which is what the odata 4 standard says, doesn't seem to work.
Unexpected token 'T' found at StringToExpression.Tokenizer.Tokenizer.Tokenize(String text)