← Prev in month ← Prev in thread
Next in thread → Next in month →

[OASIS Issue Tracker] (ODATA-572) Clarify that eq, ne can be used with complex type

From
OASIS Issues Tracker <>
Date
2015-06-11T08:12:34+00:00
ID
Thread
[OASIS Issue Tracker] (ODATA-572) Clarify that eq, ne can be used with complex type
[ https://issues.oasis-open.org/browse/ODATA-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Pizzo updated ODATA-572:
--------------------------------

    Labels: Clarification  (was: )

> Clarify that eq, ne can be used with complex type
> -------------------------------------------------
>
>                 Key: ODATA-572
>                 URL: https://issues.oasis-open.org/browse/ODATA-572
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Improvement
>          Components: OData URL Conventions
>    Affects Versions: V4.0_CS02
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>            Priority: Minor
>              Labels: Clarification
>             Fix For: V4.1_WD01
>
>
> In ODATA-400 we decided to allow JSON arrays and objects as common expressions, and the example uses the eq operators to compare an entity with a JSON-represented entity reference. The ABNF supports this, and it would be useful to use objects and arrays for eq, ne comparisons, but [URL Conventions] appears to have leftover wording that prohibits the use of collection, entity, or complex types in any logical operators.
> 5.1.1.1Logical Operators
> OData defines a set of logical operators that evaluate to true or false (i.e. a boolCommonExpr as defined in [OData-ABNF]). Logical operators are typically used to filter a collection of resources.
> Operands of collection, entity, and complex types are not supported in logical operators.
> The syntax rules for the logical operators are defined in [OData-ABNF].
> The six comparison operators can be used with all primitive values except Edm.Binary, Edm.Stream, and the Edm.Geo types.
> This prevents expression of a request such as:
>   ~odata.svc/Suppliers?$filter=Address ne {"Street": "NE 40th", "City": "Redmond", "State": "WA", "ZipCode": "98052", "Country": "USA"}
> requiring instead:
>  ~odata.svc/Suppliers?$filter=Address.Street ne "NE 40th" or Address.City ne "Redmond" or Address.State ne "WA" or  Address.ZipCode ne "98052" or Address. Country ne "USA"
> Services that follow the ABNF and other examples may already support this in 4.0, and would be compliant in doing so, but we should remove the offending statement in 4.1.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)
← Prev in month ← Prev in thread
Next in thread → Next in month →