OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

odata message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Updated: (ODATA-427) Consider Providing More Information For Changed Links In a Delta Response


     [ http://tools.oasis-open.org/issues/browse/ODATA-427?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ralf Handl updated ODATA-427:
-----------------------------

    Environment: [Applied]  (was: [Applying])

> Consider Providing More Information For Changed Links In a Delta Response
> -------------------------------------------------------------------------
>
>                 Key: ODATA-427
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-427
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData Protocol 
>    Affects Versions: V4.0_CSD01
>         Environment: [Applied]
>            Reporter: Matthew Borges
>            Assignee: Ralf Handl
>            Priority: Minor
>             Fix For: V4.0_CSD02
>
>
> Currently when a link changes, a delta response will contain only the entity-IDs of the entities and the name of the relationship.  The entity-IDs alone do not provide sufficient information for the client to build the relationship locally between the two entities because no assumptions about the entity-IDs format can be made.  For the client to make the relationship it either has to request the entities matching those IDs from the server or keep a local mapping of entity IDs to entities (a hash map of sorts).  Since no assumptions can be made about the amount of data, this mapping must be persisted, which means updating links (even with in-memory caching) in a worst case scenario requires an extra read from the persisted local store.
> To be able to locally hash the mapping for delta responses also enforces an order of operations on the server.  Links must be updated AFTER entities are changed to make sure the client gets the entities for hashing purposes before link changes.  Although this seems like a natural order, technically it is not necessary if the data store is a database that checks referential integrity on commit.
> If we can provide additional information about the entities, in particular their key values and fully qualified entity set, the above issues can be avoided.

-- 
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]