[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (ODATA-1034) Support the notion of a collection of name/value pairs where the type of the value is known
[ https://issues.oasis-open.org/browse/ODATA-1034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=65698#comment-65698 ] Michael Pizzo commented on ODATA-1034: -------------------------------------- Added proposal. Note that we could, perhaps, simplify for the consumer if we required the annotation to be on a type, rather than alternately allow it on a property whose type is open (the service would just have to define a custom complex type with the annotation in order to impose the constraint). If we want to support a constraint on the derived types, we could define an additional "DerivedTypeConstraint" term in the validation vocabulary: > Support the notion of a collection of name/value pairs where the type of the value is known > ------------------------------------------------------------------------------------------- > > Key: ODATA-1034 > URL: https://issues.oasis-open.org/browse/ODATA-1034 > Project: OASIS Open Data Protocol (OData) TC > Issue Type: Improvement > Components: CSDL JSON , CSDL XML, JSON Format, Protocol, URL Conventions > Affects Versions: V4.01_CSD01 > Environment: [Proposed] > Reporter: Hubert Heijkers > Assignee: Hubert Heijkers > Fix For: V4.01_CSD02 > > > There is currently no easy way (read: without specifying an additional wrapper entity type) of specifying a, what most people would likely refer to as a, dictionary, or a collection of name/value pair, in which I can specify the type of the values! > So where we would need to do something today like: > <EntityType Name="ValueType"> > <Key> > <PropertyRef Name="Key"/> > </Key> > <Property Name="Key" Type="Edm.String" Nullable="false"/> > <Property Name="PropA" ... /> > ... > </EntityType> > <EntityType Name="ValueTypeDictionaryWrapper"> > <Key> > <PropertyRef Name="Name"/> > </Key> > <Property Name="Name" Type="Edm.String" Nullable="false"/> > <NavigationProperty Name="Value" Type="ns.ValueType" Nullable="false"/> > </EntityType> > <AnyStructuredType Name="ValueTypeDictionaryContainer"> > ... > <NavigationProperty Name="Values" Type="Collection(ns.ValueTypeDictionaryWrapper)" Nullable="false"/> > ... > </AnyStructuredType> > Note that the wrapper has to be an entity type to be able to use the name (key) to index into the 'dictionary'. This is even a bit weirder if what we are putting in the dictionary is actually complex types that one would want to treat just like a collection of that complex type. > The payload would look something like this: > { > "@odata.context": "$metadata#AnyStructuredType(Values(Value))/$entity", > ..., > "Values": [{ > "Name": "foo", > "Value": { > "Key": "38hfgs8", > "PropA": "APropA_value", > ... > }, > "Name": "bar", > "Value": { > "Key": "f93d8r3", > "PropA": "APropA_value", > ... > }, > ... > }], > ... > } > Needless to say that this JSON representation of an, expanded, payload doesn't look like what a typical JSON consumer would expect and it requiring the wrapped value to be expanded as well.. > So what I'm looking at being able to do is, using the same example, do something like: > <EntityType Name="ValueType"> > <Key> > <PropertyRef Name="Key"/> > </Key> > <Property Name="Key" Type="Edm.String" Nullable="false"/> > <Property Name="PropA" ... /> > ... > </EntityType> > <AnyStructuredType Name="ValueTypeDictionaryContainer"> > ... > <NavigationProperty Name="Values" Type="Dictionary(ns.ValueTypeDictionaryWrapper)" Nullable="false"/> > ... > </AnyStructuredType> > And the resulting JSON payload for requests would look something like: > { > "@odata.context": "$metadata#AnyStructuredType(Values)/$entity", > ..., > "Values": { > "foo": { > "Key": "38hfgs8", > "PropA": "APropA_value", > ... > }, > "bar": { > "Key": "f93d8r3", > "PropA": "APropA_value", > ... > }, > ... > }, > ... > } > Note the more intuitive typical JSON response and that we don't need to expand the value in the wrapper any longer. -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]