You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CustomUriFunctions uses a global static dictionary at here, it's global scope, not Edm model scoped.
It's not a good design, we should fix it. see #378 (comment)
In ODL 7.x, we can introduce an new option for customers to use 'annotation' to config the customUriFuncions, but keep the static dictionary for back compatibility.
In ODL 8, remove the static dictionary
2
In OData lib parser, it starts to parse the parameter value, then uses the function name and parsed value to match the defined functions. Since there's no parameter type information at the beginning when parsing the parameter value, ODL parses the 'collection literal' as a single string value. As a result, it can't match the parameter type if we define the second parameter type as a collection of string. See details at OData/AspNetCoreOData#1003
The text was updated successfully, but these errors were encountered:
1
CustomUriFunctions uses a global static dictionary at here, it's global scope, not Edm model scoped.
It's not a good design, we should fix it. see #378 (comment)
In ODL 7.x, we can introduce an new option for customers to use 'annotation' to config the customUriFuncions, but keep the static dictionary for back compatibility.
In ODL 8, remove the static dictionary
2
In OData lib parser, it starts to parse the parameter value, then uses the function name and parsed value to match the defined functions. Since there's no parameter type information at the beginning when parsing the parameter value, ODL parses the 'collection literal' as a single string value. As a result, it can't match the parameter type if we define the second parameter type as a collection of string. See details at OData/AspNetCoreOData#1003
The text was updated successfully, but these errors were encountered: