Short Gotcha When Working With Extent Initialization In ‘M’
Not just in order to show that this Blog is still alive but also because it may be a little useful hint for all of you doing the first steps with M, the language of the Oslo Developer Center.
As you might already know you can create data models with M which are parsed and transformed into T-SQL Reference by the M-Parser.
Not only can you define Types & Values but can also assign a storage container for the defined types. Depending on the Grammar used to translate the M-File it is transformed in something that provides real storage e.g. a table in a relational database.
In the following snippet the extent definition is marked in red.
1: module MyModule {
2: type OrderItem {
3: Description : Text;
4: Quantity : Integer32;
5: }
6: OrderItems : OrderItem*;
7: }
In the sample above M does not care about how the storage is physically populated. In case of using the T-SQL variant this line would only create the table but wouldn’t insert any items (which is absolutely comprehensible behavior). However sometimes it could make sense to also initialize the storage with some values. And therefore M supports what is called extent initialization. And this works for all types supported by M and the respective data store.
So you could easily define an extent initalizer for the following type.
1: type Task
2: {
3: Id:Integer32 = AutoNumber();
4: Name:Text;
5: DueDate:DateTime?;
6: Owner:Text;
7: } where identity Id;
However if you wonder what format to use for the DueDate field and stumble across the example documented in this MSDN documentation you will probably end up with an error message like shown in the screenshot below.
The issue here is that DateTime is specified following the following lexical structures for Date & DateTime literals.
Date literals are used to write a date independent of a specific time of day. DateLiteral: Signopt DateYear - DateMonth - DateDay The tokens of a DateLiteral must not have whitespace. DateDay: one of 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 DateMonth: one of 01 02 03 04 05 06 07 08 09 10 11 12 DateYear: DecimalDigit DecimalDigit DecimalDigit DecimalDigit |
So the cause for the error is obvious as there is the sample only states a single digit for DateDay. So changing this to a double digit variant will resolve this issue. The complete lexical structure of M can be found in the MSDN library as well.
If you want to know more about ‘Oslo’ and ‘M’ check out the MSDN Developer Center and visit the blogs of Douglas Purdy and the Intellipad Team.