[OASIS Issue Tracker] (ODATA-976) Support partial keys

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

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

Michael Pizzo updated ODATA-976:
--------------------------------

    Description: 
In OData-945 we added support for composite keys expressed through key-as-segment, which begged the question what happens if only part of the key is specified.  It seems reasonalbe that, in this case, we would do a partial filtering of the results.

i.e.;

    AccountingDocuments/SAP/2016

would identify the subset of accounting documents for a company and year, and

    AccountingDocuments/SAP

would identify the subset of accounting documents for a company.

Services could optionally support this as a shorthand for 

   GET AccountingDocuments?$filter=CompanyCode eq 'SAP' and Year eq '2016'

and

   GET AccountingDocuments?$filter=CompanyCode eq 'SAP'

If supported, we should define consistent semantics across both key-as-segment and parens-syntax.

Note that the rules for disambiguation would be a little inconsistent. Normally we interpret a path segment first as a property, then as a function/action, then as a property.  If we support partial keys then the resolution rules become a bit tricky -- if the previous segment matches a partial key value then the next segment would be matched as a partial key value before anything else.

  was:
In OData-945 we added support for composite keys expressed through key-as-segment, which begged the question what happens if only part of the key is specified.  It seems reasonalbe that, in this case, we would do a partial filtering of the results.

i.e.;

    AccountingDocuments/SAP/2016

would identify the subset of accounting documents for a company and year, and

    AccountingDocuments/SAP

would identify the subset of accounting documents for a company.

Services could optionally support this as a shorthand for 

   GET AccountingDocuments?$filter=CompanyCode eq 'SAP' and Year eq '2016'

and

   GET AccountingDocuments?$filter=CompanyCode eq 'SAP'

If supported, we should define consistent semantics across both key-as-segment and parens-syntax.


> Support partial keys
> --------------------
>
>                 Key: ODATA-976
>                 URL: https://issues.oasis-open.org/browse/ODATA-976
>             Project: OASIS Open Data Protocol (OData) TC
>          Issue Type: Sub-task
>          Components: OData URL Conventions
>    Affects Versions: V4.0_ERRATA02
>         Environment: New Query Capabilities
>            Reporter: Ralf Handl
>             Fix For: V4.01_WD01
>
>
> In OData-945 we added support for composite keys expressed through key-as-segment, which begged the question what happens if only part of the key is specified.  It seems reasonalbe that, in this case, we would do a partial filtering of the results.
> i.e.;
>     AccountingDocuments/SAP/2016
> would identify the subset of accounting documents for a company and year, and
>     AccountingDocuments/SAP
> would identify the subset of accounting documents for a company.
> Services could optionally support this as a shorthand for 
>    GET AccountingDocuments?$filter=CompanyCode eq 'SAP' and Year eq '2016'
> and
>    GET AccountingDocuments?$filter=CompanyCode eq 'SAP'
> If supported, we should define consistent semantics across both key-as-segment and parens-syntax.
> Note that the rules for disambiguation would be a little inconsistent. Normally we interpret a path segment first as a property, then as a function/action, then as a property.  If we support partial keys then the resolution rules become a bit tricky -- if the previous segment matches a partial key value then the next segment would be matched as a partial key value before anything else.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)