MSchema: An Example - Part 2

Silverlight Logo

If you have read Part 1 of this series, you have seen how to create types, collections and constraints using MSchema. Along with most database schemas, I find the need to create some amount of data to go along with those schemas. For my current project (our new web site), I wanted to have some small set of data that included some basic workshops and locations.

To create the data we can use the MGraph language. MGraph is related to MSchema but is a way of describing concrete instances of data. To create an instance:

module Training
{
  Workshop
  {
    {
      Name = "Silverlight Workshop",
      Description = "A three day workshop to teach Silverlight 2.",
      Length = 3,
      MaxAttendees = 16,
      DefaultPrice = 1800.00
    },
    {
      Name = "Advanced Silverlight",
      Description = "Two-day course teaching advanced Silverlight topics.",
      Length = 2,
      MaxAttendees = 16,
      DefaultPrice = 1200.00
    }
  }
}

The syntax looks similar to a mix between the C# object initialization syntax and JSON. The module matches the same module that the schema was defined in. Then it is the extent name (Workshop in this case) then an array of objects (notice the types defined inside curly braces). This can be used to generate insert statements. That's easy to do with actual insert statements, so why learn this format at all? 

Foreign keys are what make this fun. If we wanted to add an event (who has a reference to a Workshop) we would need to be able to tell the MGraph language how to make the reference. I innocently thought of this approach:

  Event
  {
    {
      WorkshopId = 1,
      EventDate =  2009-02-04     
    }
  }

I assumed that I could set the id's manually then use them...to my surprise MGraph handles that better that I guessed.  how so?  The creation of the instances can be named.  So if we change the workshop creation to use names like so:

  Workshop
  {
    SilverlightWorkshop {
      Name = "Silverlight Workshop",
      Description = "A three day workshop to teach Silverlight 3.",
      Length = 3,
      MaxAttendees = 16,
      DefaultPrice = 1800.00
    },
    AdvancedSilverlight {
      Name = "Advanced Silverlight",
      Description = "Two-day course teaching advanced Silverlight topics.",
      Length = 2,
      MaxAttendees = 16,
      DefaultPrice = 1200.00
    }
  }

Now that the workshops are named, we can define our events with the names:

  Event
  {
    {
      WorkshopId = Workshop.SilverlightWorkshop,
      EventDate =  2009-02-04     
    }
  }

Now when we create the event, we can use the workshop (notice the Workshop is prefixed) to say that the workshop for this event is the one we created above.  M takes care of the rest. 

In the next part, we will show the command-line tools you can use to store the schemas and data in the database.

Comments:

Gravatar

"That's easy to do with actual insert statements, so why learn this format at all?"
That is just the question. What are the benefits of using this approach?

Gravatar

Two benefits I think. One, the relationships are hard to get right in INSERTS so created related (e.g. FK's) in this format seem more natural to me. Two, I find this style is easier for me to write than INSERT where the SQL language gets in my way. Its not a Better/worse, its an abstraction over the SQL.

Gravatar

Rodrigo, The benefits of using this approach is that the syntax of actual insert statements in SQL may vary depending on the Database. Depending on the RDBMS (e.g. Oracle,DB2,mySQL,SQL Server you may want to generate different insert SQL's.) This makes Mcchema database technology agnostic.

Gravatar

Mahesh,

While MSchema is agnostic, it isn't yet. The tooling is SQL Server only (TSQL I should say). I expect in further CTP's that it will support more DB's, but today its not.

Gravatar

Shawn,

Thanks for your perspective.

Yes. Future support for more DB's will happen.

As one of the MSDN OSLO web pages suggests - " In addition, because that data is captured in the “Oslo” repository, it is available to all kinds of tools that specialize in structured data, whether these tools are design tools like “Quadrant” or third-party tools that can sift, search, and filter the information to make available information that is very difficult to understand using current tools."

In fact, support for non SQL Server has to be one of Microsoft's key strategic objectives for OSLO.


 



 
Save Cancel