[Tutorial & Sample] How to Use Open Type in OData

OData protocol introduces conception of open type which allows clients to add properties dynamically to instances of the type by specifying uniquely named values in the payload used to insert or update an instance of the type. This makes definition of entity type or complex type more flexible. Developers do not have to define everything which is probably used in the edm model.

Server Side

1. Model Definition

It is quite easy to define an open entity type or open complex type in server side.

If a server uses CSDL file to define the data model, only adding an attribute OpenType="true" to the node of the entity type or the complex type definition is needed. For example,

Open entity type:

Open complex type:

If a server uses EdmModel to define a data model, the parameter isOpen should be true when construct an entity type or complex type as open. For example,

Open entity type:

Open complex type:

According to the OData protocol, the default values of OpenType and isOpen are false.

2. Uri Parse

When query a dynamic property (A property, in open type, not declared in the edm model is called “dynamic property” because it is added by clients dynamically), the query uri can be something like: "~/Categories(0)/DynamicPropertyName" or "~/AccountInfo/DynamicPropertyName". If service calls ODataUriParser to parse the uri, the last segment of the uri should be OpenPropertySegment.

Client Side

At client side, developers can use OData client code generator to generate OData client code. For more details, please refer to How to Use OData Client Code Generator. In the generated codes, a class which represents an entity type and complex type is defined as a partial class. Developers can add properties into the specific class as dynamic properties. The added code is similar as those generated code for a declared property.

For example, declare a dynamic property with property name as “Description” in Category which is an open entity type. If interested, people can have try against the OData (read/write) service.

It is in same way to declare a dynamic property in an open complex type.

Then the client will treat them as any other properties. So users can use the dynamic property in the same way as a declared property.

Sample Code:

Comments (4)
  1. Uffe says:

    Are open navigation properties supported in version 6.x? It Was not supported in 5.x.

  2. @Uffe. ODL does not support dynamic navigation properties in version 6.x. But, could you share some info about your scenario? How will you use dynamic navigation properties in your scenario?

  3. Uffe says:

    Hi Liang,

    My idea is to to use open types to ensure backwards compatibility while reducing our metadata model. Currently we can have up to 4 different navigation properties between two types/sets that all represents the logic same reference. I would like to detect this during my metadata generation and ensure we only expose one of them. To be backwards compatible with existing client code i would like to keep the remaining (up to 3) navigation properties as dynamic/open. This would greatly reduce our model and make the client developer experience better in the future. Regards Uffe

  4. Sund says:

    This doesn't seem to work with a weak type (untyped) setup.

    When constructing an EdmComplexObject from an 'Open' EdmComplexType, there is still only the 'TrySetPropertyValue' methods which do not set open type values.

Comments are closed.

Skip to main content