 |
|||||||||
|
|||||||||
|
|
In my last blog post on Oslo , I walked through a simple scenario where we created an "M" file that contained the models for a fictitious science fiction game. We used this file and IntelliPad to see what the T-SQL might look like if we were to create just the tables defined by the model. In this blog post, I'm going to walk through the process of taking an "M" model, compiling it into an MX image, and finally storing that image in the repository.
If you're following along, you can grab the "M" file that I created in the previous blog post or you can create your own. The repository is a central storage location for models. Not only does it contain the actual schemas generated by your model image, but it also contains a lot more like security and versioning information. In the interest of keeping this post as small as possible I won't go into too much detail, but you can find tons of Repository-related videos over on the Oslo Developer Center .
The first thing we need to do is compile our model. To do that, we'll use the command-line tool that ships with the CTP called m.exe. This tool can be used to generate regular T-SQL, repository SQL, and of interest to us: a repository image of the model. Sticking with the M file I created last time, I can open up a command prompt, make sure the Oslo SDK "bin" directory is in my path and issue the following command:
m UlyssesAgenda.m /p:image
The output is a file named UlyssesAgenda.mx. This is a compiled M file. Now we need to get the compiled M image into the repository. Using this CTP we can accomplish that from the command-line as well using the MX utility:
mx -i:UlyssesAgenda.mx -d:Repository -s:kev-win7\SQLEXPRESS
Depending on your configuraiton, you may not need the "-s" command line switch to indicate the server where the Repository database is stored. In my case, I have a full-blown installation of SQL Server 2008 and SQLEXPRESS is not my default instance so I've found that every now and then that means I have to modify connection strings or, in this case, pass the server/instance explicitly.
And now we can look at SQL Manager and we see that all of the tables that correspond to our high-level model were created:
Using the MX command-line tool we can also directly query the repository. I thought it worth showing the output of this because it illustrates one of the more valuable aspects of Oslo - model versioning:
>mx -l -d:Repository -s:kev-win7\SQLEXPRESS
Microsoft (R) code name "M" Command-line Utility version 1.0.1308.1
Copyright (C) Microsoft Corporation. All rights reserved.
Contents of the database
============================================================
Models.mx Models.mx;Version=1.0;Locale=neutral
UlyssesAgenda UlyssesAgenda;Version=1.0;Locale=neutral
Models.mx is the compiled list of all of the stock models that Microsoft has provided and put into the database as part of the core Oslo offering. What I think is really important to keep track of is that the models themselves are versioned. There are no table versions - the versioning takes place at the model level which is, IMHO, where it should be. Also keep in mind that because at the lowest level we've also created a standard SQL schema, you can use any tool you like against this server, including LINQ to SQL or ADO.NET or the Entity Framework.
So now we've created a model and put it in the repository. In upcoming blog posts, I'm going to cover some of the other interesting things that you can do with models.
rake db:migrate. :). Again I'm not saying it's the -same- thing and this
is probably much more generalized for many platforms. Aside from SQL
server, what other kinds of repositories can mc write a model to.
Jamie, obviously you're a Ruby/Rails person... But you'll notice that I
never once mentioned anything about _web_ applications in this blog post. I
was able to take a model and store it in a versioned repository. Even Ruby
doesn't version a model repository... It's up to you to manipulate your
migration scripts with sequence numbers so that you can tear down and build
up changes in your database. This is better than that - I can version the
entire model at the "M" level (which is a very easy to read syntax, and can
be visually designed as well). Rake migrations are specifically for RoR
websites and aren't really capable of being used anywhere else (yes I know
you _can_... but why would you???). The entire purpose behind these series
of blog posts is twofold : 1) so that I can learn more about Oslo by doing
blog posts about Oslo, 2) so that people can see that Microsoft is taking
the modeling problem seriously and coming up with solutions to allow people
who build huge-ass data-heavy applications to go with the model-driven
development pattern without having the lack of tooling and the other
frustrations make people give up.
I haven't really done rails in a long time, not seriously, and I don't
think we have any disagreement.
So how is this part different from having a special table with blob/text
containing the model file and a kind of wrapper loading this version of the
file into the SQL database table definition?
Pieter- I found these, it's very interesting...
One thing that I really don't get with Oslo is the fact that the repository
is a SQL Server DB. Surely this is restricting my models to the limits of
SQL Server. There are some XSD constructs that I cannot do very easily in
SQL Server. What about modeling services and SOAP porttypes? Also, I was
expecting Quadrant to be a model editing tool, rather than a generic
graphical DSL.
