March 4, 2021
Hot Topics:

Exploring the Oslo Repository

  • By Jeffrey Juday
  • Send Email »
  • More Articles »

As I mentioned earlier, the best way to understand a model in M is to look at a sample. If you've ever built a database in TSQL, designed an XML schema, and done any C# development, M concepts and structure will be familiar to you. Following is sample code from the Application.m sample.

module System.Application
   import System;
   import System.Management.Lifecycle;

   export Application;
   export Applications;

   Applications : Application* where
      item.Id in SoftwareComponents.Id,
      item.DefinedInApplication in Applications,
      item.LifecycleState in LifecycleStates;

   // A composite SoftwareComponent or "software system".
   // Composed of a deployment and a management unit.
   type Application : Manageable, DerivedItem
      DefinedInApplication : Application?;



According to CTP documentation, the components contained in the module System.Application: "represents a "Software System" composed of SoftwareModules and other Applications. An Application is a deployment and management unit."

The "parts" of System.Application.Application are broken down into their particular M components as follows.

  • M code is contained in a Module. Modules are groupings of related things. Module naming works similar to namespaces in C#. If you explore other pieces of code, other .m files are located inside System.Application modules.
  • The import statement works a lot like the using statement in C# or the import statement in VB.NET. Export is similar to a public statement in C# and VB.NET.
  • "Application: Application*" declares a collection of type Application.
  • "item.Id in" works like a Foreign key declaration in TSQL.

"type Application :" would appear to be creating a type inheriting from other types, but that's not the correct way to interpret this. There is no inheritance in M. Rather, the syntax declares a type that conforms to or "looks like" the Manageable type and DerivedItem type.

The "?" after Application simply means that the DefinedInApplication Field can be set to NULL. The concept is similar to declaring NULL after a TSQL column declaration.

For a more complete introduction to M, the SDK documentation is pleasingly thorough. The "documents" folder in the SDK directory contains many M resources.

With a taste of M and background on a sample model, I'll turn to how the model gets loaded into the Repository.

From M into SQL Server

The Repository is a SQL Server database. Making Repository a SQL database creates a number of opportunities for developers. SQL Server has quite a few reporting, querying, auditing, recovery, scalability, and "data" features. Putting model data in SQL Server allows a developer to leverage these features.

The Repository includes some base supporting table and views.

Models are compiled to an intermediate format ".mx" file and loaded into the Repository using the MX.EXE utility. Some typical MX.EXE command line usage appears below.

mx /i:models.mx /db:Repository /s:ServerName

The M model code is translated into TSQL, creating all the supporting tables, views, and keys in the Repository database. The resulting TSQL code for the System.Application.Application model can be viewed in Intellipad and some of the TSQL appears below.

CREATE TABLE [System.Application].[ApplicationsTable](
   [Id] [bigint] NOT NULL,
   [DefinedInApplication] [bigint] NULL,
   [Folder] [int] NOT NULL,
   [LifecycleState] [bigint] NULL,
   [Id] ASC
)WITH (PAD_INDEX               = OFF,
       IGNORE_DUP_KEY          = OFF,
       ALLOW_ROW_LOCKS         = ON,


ALTER TABLE [System.Application].[ApplicationsTable]
   CONSTRAINT [FK_Applications_DefinedInApplication_System.
   FOREIGN KEY([DefinedInApplication])
REFERENCES [System.Application].[ApplicationsTable] ([Id])

ALTER TABLE [System.Application].[ApplicationsTable]
   CHECK CONSTRAINT [FK_Applications_DefinedInApplication_System.

ALTER TABLE [System.Application].[ApplicationsTable]
   ADD DEFAULT ((100)) FOR [Folder]

Modules are expressed in the TSQL Schema. In the example above, the Schema is System.Application.

Page 2 of 3

This article was originally published on December 8, 2008

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date