[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Commented: (ODATA-296) Change tracking may require server-side state, but client cannot advise server to stop tracking in order to allow server to release resources
[ http://tools.oasis-open.org/issues/browse/ODATA-296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=33344#action_33344 ]
Evan Ireland commented on ODATA-296:
------------------------------------
Ralf wrote:
"the system can figure out that Jim's move from CA to NY happened after the timestamp and makes Jim fail the filter"
Suppose the delta handling is implemented with a SQL query:
select * from Customer where state = 'CA' and lastModified >= :lastModified
So now if Jim moves to 'NY', it will not be returned in the results of that query (only new/update customers in 'CA" will be returned), so that query cannot be used for determining deleted entries. We could run this query instead:
select * from Customer where not (state = 'CA') and lastModified >= :lastModified
That means that any client fetching a deltaLink after Jim's update will need to be sent a deletedEntry for Jim (if that client's current filter does not match "NY"), even if those clients never previously had received "Jim". That could be highly inefficient (as there are many other states). It also helps us to appreciate that many "simple" implementations of change tracking may turn out to be either "buggy" or "inefficient" (awith large data sets), if they don't take what we call "partition membership changes" into account.
In any case, we can agree that solving this with per-client state is an implementation variant, not a necessity. However that is why I proposed that if the server does not keep per-client state for change tracking (in which case it might well be either buggy or inefficient), it could ignore DELETE issued against a deltaLink.
> Change tracking may require server-side state, but client cannot advise server to stop tracking in order to allow server to release resources
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: ODATA-296
> URL: http://tools.oasis-open.org/issues/browse/ODATA-296
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Improvement
> Components: OData Protocol
> Affects Versions: V4.0_WD01
> Environment: [Proposed]
> Reporter: Evan Ireland
> Fix For: V4.0_WD01
>
>
> The protocol spec (2013-03-12) states in section 10.3 Requesting Changes:
> "The delta link MUST conceptually encode the following information..."
> One common implementation of change tracking (where filters are used in the original request) is for the server to persist some state (for each client that it is tracking changes for), e.g. a list of primary keys. Otherwise it can be difficult or expensive to calculate an appropriate delta set when the client wants to receive updates, especially if filtered (non-key) properties have been changed in the interim.
> (In particular, if the server does not persist some state for each client, the size of a delta link may be excessive if the set of tracked entities is large).
> The problem here is that the OData protocol doesn't appear to define a mechanism for a client to notify the server:
> (1) That it no longer wishes the server to track changes for it, or
> (2) That it wishes to modify its filter criteria.
> So for issue (1) the server doesn't have the opportunity to delete any server resources (e.g. persistent state) that it has retained on behalf of the client.
> And for issue (2) if the client uses a brand new filter with change tracking enabled, the server doesn't have the opportunity to optimize the returned results so as to avoid resending data that happens to exist in both old and new result sets.
> We may decide that the second issue should be deferred to post V4.
> But the first one could easily be addressed if we allowed a DELETE request to be sent to a delta link. If the server doesn't use persistent state for delta links, the DELETE for delta links can be trivially implemented! And if the server does use persistent state, then it would be able to free up resources (assuming co-operative clients).
--
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]