[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (ODATA-165) Support Cross-joins
[ http://tools.oasis-open.org/issues/browse/ODATA-165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=32758#action_32758 ]
Stefan Drees edited comment on ODATA-165 at 3/17/13 9:04 AM:
-------------------------------------------------------------
As this seems to be the last remaining "active class 1" issue (Type=Bug and Priority=Major),
are we close to a proposal with target V4.0_WD1 or should we defer to one out of (V4.1, V5.0) ?
Based on the suggestions from the latest data aggregation extension document (at the end) I'd phrase it as follows:
Proposal:
The ability to pose queries that span entity sets not related by an association provides a mechanism for advanced consumers to pose queries across entity sets based on other join conditions, where the client may $expand the entity sets to be joined, and add a filter to specify the equivalent of the join condition.
To enable this often requested capability, the server MUST allow requests to be rooted at the entity container, in doing so the latter MUST either provide explicit navigation properties in the model (i.e. where useful navigations exist) or MUST define implicit navigation properties with cardinality "to one" to each entity set (and potentially each function) it contains, so that queries across entity sets could be supported by referring to properties qualified by entity set.
In any of the two cases, the entity container SHOULD be annotated in the same way as entity sets to express which aggregate queries are supported.
For example, if Customers and Countries were in separate entity sets with no defined relationship, to query all Customers for a particular country based on a common country code one could then pose the following query (given the sample data as described in the data aggregation extension document):
GET ~SalesData?$select=Customers/Name,Countries/Name\
&$expand=Customers,Countries\
&$filter=Customers/CountryCode eq Countries/CountryCode and Countries/Name eq 'USA'
would return(as partial result):
[
{
Customers: [
{
Name: "Joe"
}
],
Countries: [
{
Name: "USA"
}
]
},
{
Customers: [
{
Name: "Sue"
}
],
Countries: [
{
Name: "USA"
}
]
}
]
What do the others think?
was (Author: sdrees):
As this seems to be the last remaining "active class 1" issue (Type=Bug and Priority=Major),
are we close to a proposal with target V4.0_WD1 or should we defer to one out of (V4.1, V5.0) ?
Based on the suggestions from the latest data aggregation extension document (at the end) I'd phrase it as follows:
Proposal:
The ability to pose queries that span entity sets not related by an association provides a mechanism for advanced consumers to pose queries across entity sets based on other join conditions, where the client may $expand the entity sets to be joined, and add a filter to specify the equivalent of the join condition.
To enable this often requested capability, the server MUST allow requests to be rooted at the entity container, in doing so the latter MUST either provide explicit navigation properties in the model (i.e. where useful navigations exist) or MUST define implicit navigation properties with cardinality "to one" to each entity set (and potentially each function) it contains, so that queries across entity sets could be supported by referring to properties qualified by entity set.
In any of the two cases, the entity container SHOULD be annotated in the same way as entity sets to express which aggregate queries are supported.
For example, if Customers and Countries were in separate entity sets with no defined relationship, to query all Customers for a particular country based on a common country code one could then pose the following query (given the sample data as described in the data aggregation extension document):
GET ~SalesData?$select=Customers/Name,Countries/Name\
&$expand=Customers,Countries\
&$filter=Customers/CountryCode eq Countries/CountryCode and Countries/Name eq 'USA'
would return(as partial result):
[
{
Customers: [
{
Name: "Joe"
}
],
Countries: [
{
Name: "USA"
}
]
},
{
Customers: [
{
Name: "Sue"
}
],
Countries: [
{
Name: "USA"
}
]
}
]
What od the others think?
> Support Cross-joins
> -------------------
>
> Key: ODATA-165
> URL: http://tools.oasis-open.org/issues/browse/ODATA-165
> Project: OASIS Open Data Protocol (OData) TC
> Issue Type: Bug
> Components: OData Protocol
> Reporter: Michael Pizzo
> Assignee: Michael Pizzo
>
> We often have requests to support queries that span entitysets. Where navigation properties exist between the entitysets these provide a natural and convenient mechanism for building queries that span entitysets. However, where navigation properties are not present a way is needed to build such cross-entity spanning queries.
> In the context of looking at aggregation we came up with a solution for doing this by considering the entitycontainer as the cross-product of the contained entitysets. You could then $expand the entitysets you wanted to join, and add a filter to specify the equivalent of the join condition. This seemed generally useful beyond just the scope of aggregation.
--
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]