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] Commented: (ODATA-528) $entity should require cast segment in order to apply $select/$expand


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

Hubert Heijkers commented on ODATA-528:
---------------------------------------

I don't like the idea that we would require the cast, to me that kind of defeats the purpose, but then and again if the requester doesn't know the type he likely won't know what to select and expand either. Also I've just been told that this is the once case were we would need the cast ourselves as well short of looking ahead to the $id and resolving it (which we could), everywhere else we know the exact type. Which gets me to what caught my attention as in 'everywhere else we consistently require casting'. Do we mean by that that we need the case in the select and expand clauses before we can select/expand a property of a given, typically, sub-type?

So given that we need the case for $select and $expand shouldn't the fixed abnf look something like:

  $entity "/" qualifiedEntityTypeName "?" entityOptions 
/ $entity "?" *( customQueryOption "&" ) id *( "&" customQueryOption )

to make explicit that the qualified entity type name segment is required in combination with a $select and $expand instead of being optional?

> $entity should require cast segment in order to apply $select/$expand
> ---------------------------------------------------------------------
>
>                 Key: ODATA-528
>                 URL: http://tools.oasis-open.org/issues/browse/ODATA-528
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Bug
>          Components: OData ABNF Construction Rules, OData Protocol 
>    Affects Versions: V4.0_CS01
>         Environment: [Proposed]
>            Reporter: Michael Pizzo
>             Fix For: V4.0_CSD03
>
>
> Given an opaque id for an entity, the client can get the instance using the new /$entity resource and providing the id through the $id query option, such as:
> http://host.service/$entity?$id=urn:mysvc5304-98001-7832-4425
> This can be cast to a particular type:
> http://host.service/$entity/myservice.Customer?$id=urn:mysvc5304-98001-7832-4425
> And any of the query options supported for a single resource can be applied:
> http://host.service/$entity/myservice.Customer?$id=urn:mysvc5304-98001-7832-4425?$select=LastName&$expand=Orders
> However the text current does no require the cast in order to apply $select and $expand. This is a bug, because without the cast a parser cannot determine whether the $select and $expand are valid without actually retrieving the object and discovering its type.
> Everywhere else we consistently require casting to the correct type in order to access members of that type.
> Also, I think there is a bug in the ABNF as it doesn't appear to allow for the cast segment:
> '$entity' "?" entityOptions  

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