Since data is the basis for all OData feeds it is natural to see then that describing the data that represents the types Entities with in the feed is important. It is not only important for the data but also for the metadata that plays a significant role in the OData protocol.
The OData protocol is a very structured standard and with it also come a set of primitive data types. Each data type has a distinct set of properties themselves and we will look at each and understand those characteristics. Let’s dig into the list shall we?
What are the Data Types for OData?
I will give the list of primitive data types that can be used with the OData protocol and additionally I will give some of the characteristics for each type. We all should know most of these data types but it will be a good refresher.
|
Primitive Types |
Description |
Notes |
Examples |
|
Null |
Represents the absence of a value |
null |
|
|
Edm.Binary |
Represent fixed- or variable- length binary data |
X and binary are case sensitive. Spaces are not allowed between binary and the quoted portion. Spaces are not allowed between X and the quoted portion. Odd pairs of hex digits are not allowed. |
X’23AB’ |
|
Edm.Boolean |
Represents the mathematical concept of binary-valued logic |
Example 1: true Example 2: false |
|
|
Edm.Byte |
Unsigned 8-bit integer value |
FF |
|
|
Edm.DateTime |
Represents date and time with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D. |
Spaces are not allowed between datetime and quoted portion. datetime is case-insensitive |
datetime’2000-12-12T12:00′ |
|
Edm.Decimal |
Represents numeric values with fixed precision and scale. This type can describe a numeric value ranging from negative 10^255 + 1 to positive 10^255 -1 |
2.345M |
|
|
Edm.Double |
Represents a floating point number with 15 digits precision that can represent values with approximate range of ± 2.23e -308 through ± 1.79e +308 |
Example 1: 1E+10 Example 2: 2.029 Example 3: 2.0 |
|
|
Edm.Single |
Represents a floating point number with 7 digits precision that can represent values with approximate range of ± 1.18e -38 through ± 3.40e +38 |
2.0f |
|
|
Edm.Guid |
Represents a 16-byte (128-bit) unique identifier value |
‘12345678-aaaa-bbbb-cccc-ddddeeeeffff’ |
|
|
Edm.Int16 |
Represents a signed 16-bit integer value |
Example 1: 16 Example 2: -16 |
|
|
Edm.Int32 |
Represents a signed 32-bit integer value |
Example 1: 32 Example 2: -32 |
|
|
Edm.Int64 |
Represents a signed 64-bit integer value |
Example 1: 64L Example 2: -64L |
|
|
Edm.SByte |
Represents a signed 8-bit integer value |
Example 1: 8 Example 2: -8 |
|
|
Edm.String |
Represents fixed- or variable-length character data |
Example 1: ‘Hello OData’ |
|
|
Edm.Time |
Represents the time o |
Example 1: 13:20:00 |
|
|
Edm.DateTimeOffset |
Represents date and time as an Offset in minutes from GMT, with values ranging from 12:00:00 midnight, January 1, 1753 A.D. through 11:59:59 P.M, December 9999 A.D |
Where do the Data Types for OData come from?
Where do the datatypes for OData originate is a great look at the history of OData and what other products helped shape the protocol. OData originated with Microsoft so first we will look at where most data resides when developing solutions on the Microsoft stack of tools and technologies: SQL Server. When the OData protocol was announced back in 2010 most of the data types used in Microsoft SQL Server 2008 could be used to represent data in an OData feed. It would only seem logical that a technology that was developed with an organization would be shaped and influenced by the tools at hand and OData is no exception.
But that is just the start. We must also look at the Entity Framework as another key influencer in the maturation of the OData protocol. If you notice in the table above the list of the data types all have the prefix “Edm.” associated. That comes from the Entity Framework to mean “Entity Data Model”. Why is this so? It could be that other data types will be allowed at some time and that some with the same literal name could be brought into the OData protocol specification but with slightly different characteristics. If that happened these new set of primitives could conflict with the existing data types (example could be datatypes from Oracle).
The OData team was smart enough to allow for this and started using prefixes that could distinguish possibly a different representation of a string by two different database products (example could be the maximum fixed length of a string). These new data types could be given their own prefix and happily live side by side with the original data types from SQL Server and Entity Framework.
What about Spatial Data Types?
The Spatial data types that first were brought to the Microsoft world in SQL Server 2008 are a new exciting feature of both the Entity Framework 4.0 product but also for OData. These new data types are so exciting that I will be spending an entire blog post covering these later in the month. I will update and link this blog post chapter to that future post so stay tuned.
Pingback: Windows Azure and Cloud Computing Posts for 12/3/2011+ - Windows Azure Blog