[OASIS Issue Tracker] Commented: (ODATA-295) Services should be able to "advertise" what form of change tracking they support

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/ODATA-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33512#action_33512 ] 

Michael Pizzo commented on ODATA-295:
-------------------------------------

Is there a way to use the term to explicitly state that change tracking is not supported? Or must the client assume that, in the absence of this annotation, change tracking is not supported?

Is the idea behind FilterableProperties that a service may ignore properties in a filter not on the list (i.e., over notify) or that it wouldn't return a delta link if the set and a filter on such a property? I would recommend we clarify the description as the later, as the former would require the client to evaluate the filter locally on all returned instances to see whether or not they were a member of the set (which is not the case today; the service is required to honor the filter or not return a delta link). Perhaps reword as:

  <Annotation Term="Core.Description" String="Change tracking supports filters on these properties" /> 

Also, it might be nice to also include whether or not change tracking supports expands (and even on which navigation properties).

Perhaps add to "ChangeTrackingType" the following:

<Property Name="ExpandableProperties" Type="Collection(Edm.NavigationPropertyPath)" Nullable="true">
  <Annotation Term="Core.Description" String="Change tracking supports these properties expanded"/>
</Property>


> Services should be able to "advertise" what form of change tracking they support
> --------------------------------------------------------------------------------
>
>                 Key: ODATA-295
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-295
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: New Feature
>          Components: OData CSDL, OData Protocol 
>    Affects Versions: V4.0_WD01
>         Environment: [Proposed]
>            Reporter: Evan Ireland
>             Fix For: V4.0_WD01
>
>
> Protocol spec (2013-03-12) states in section 10.3 Requesting Changes.
>   Services MAY support requesting changes for arbitrary queries against the entityset or MAY require that any filters be applied solely to immutable (i.e., key) fields.
> Now suppose that a client is interested in change tracking for a particular entity set, using a filter.
> The client must first try the query with the filter (and with odata.track-changes preference), and will get a result, but it may finally prove to have no delta link (the client has no way to know in advance if the server will provide a delta link).
> Then the client (if the server doesn't provide a delta link) may need to try the query again without a filter, and then somehow apply the filter "locally" (on the client-side). Again the client may discover that the server doesn't support change tracking (even for the case without a filter).
> It would be much preferred by client application and framework designers for OData services somehow to be able to "advertise" their support (or not) for change tracking (and any limits that are placed upon it, such as what kind of filters can be used), rather than the clients having to discover by a process of trial and error.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira