Understanding HasExtentName / Mixin / Inheritance

Thu, 04 Jun 2009 12:08:21 Z

In the Models\Repository\System directory there is a type called HasExtentName:

module System
{
    export HasExtentName;

    // Mixin used to include an extent name field in the root extent of a vertical partition
    // when implementing a generalization hierarchy that allows only single parenting.
    type HasExtentName
    {
        ExtentName: Text;
    }

}

It seems like this pattern was used for example in Microsoft.Samples.Process.Activities where each activity has an ExtentName referencing a database of its particular subtype (e.g. UserTasks, Decisions...).

Now I wonder how you would implement this Mixin pattern and how it actually differs from the inheritance pattern using a discriminator field (as shown here: http://blogs.msdn.com/dave_langer/archive/2009/06/02/modeling-inheritance-in-oslo-s-m.aspx, Table per Concrete Class ). Intuitively, I would say, you use "ExtenName" as a discriminator field, but then again I would end up defining constraints for the allowed subtypes (UserTasks, Decisions,...).

Could you provide a simple example (MSchema and MGraph) how to apply the "HasExtentName" (maybe you could stick to the example provided in the article above: Department has different kinds of Employees) ?

Understanding HasExtentName / Mixin / Inheritance

Sat, 06 Jun 2009 03:36:19 Z

Just a quick note--I'll find someone to answer this for you on Monday. Have a great weekend and thanks for all your provocative posts this last week!

.Kraig

Understanding HasExtentName / Mixin / Inheritance

Sat, 06 Jun 2009 15:54:49 Z

Thanks Kraig. And thank you for taking time to answer all these questions.

Understanding HasExtentName / Mixin / Inheritance

Fri, 12 Jun 2009 15:25:24 Z

Someone should be getting back to you shortly. Sorry it's taking so long.

Understanding HasExtentName / Mixin / Inheritance

Fri, 12 Jun 2009 17:16:22 Z

Sorry this has taken so long!

The type System.HasExtentName is a hangover from an earlier approach to modeling generalization and was intended to be used as you surmised. That pattern has been dropped in favor of other approaches that have broader use -- the extent name pattern arose from consideration of just one of the implementation patterns - extent/table-per-type - and had many limitations. We will be removing HasExtentName in the next drop so I suggest you pretend it was never there! Modeling generalization is an important scenario for us and is hugely important in our UML model, where you can already see some evidence of some of the patterns we're using. Stay tuned for more on this topic soon!

Bill

Understanding HasExtentName / Mixin / Inheritance

Sun, 14 Jun 2009 16:34:42 Z

Ok, thank you for clearing that up.

I stay tuned ;)

Understanding HasExtentName / Mixin / Inheritance

Wed, 01 Jul 2009 11:28:53 Z

Hello,

I've got a further question about the implementation of the inheritance pattern discussed here. (Even though you said it will be dropped in future versions, I still consider it as the best approach at the moment ).

This time it's not about the extent name issue. I'm interesting in the way you model the child class in terms of Primary Key, Foreign Key, and unique constraint.

Let me explain it: So far I know three different ways to model the child class (see below). All three versions work fine for me.

Do you see any advantages/disadvantages for any of these versions, in terms of both "M" and SQL considerations?

// Version 1 (PK = FK), based on Shawn Wildermuth's version (http://wildermuth.com/2008/11/08/MSchema_and_Decorator_Tables)
module Demo
{
    type Person
    {
        name : Text;
        ID   : Integer32 => AutoNumber();
    } where identity ID;

    type Employee
    {
        jobTitle : Text;
        person   : Person;
    } where identity (person), value .person in Persons;

    Employees : Employee*;
    Persons : Person*;
}

// Version 2 (PK, FK = UNIQUE), based on the [Microsoft.Samples.Processes.Process] models
module Demo
{
    type Person
    {
        name : Text;
        ID   : Integer32 => AutoNumber();
    } where identity ID;

    type Employee
    {
        person   : Person;
        jobTitle : Text;
        employeeID : Integer32 => AutoNumber();
    } where identity (employeeID), unique (person), value .person in Persons;

    Employees : Employee*;
    Persons : Person*;
}

// Version 3 (compound FK, PK), my own version
module Tests.EmployeeInheritance
{
    type Person
    {
        name : Text;
        ID   : Integer32 => AutoNumber();
    } where identity ID;

    type Employee
    {
        jobTitle : Text;
        person   : Person;
        employeeID : Integer32 => AutoNumber();
    } where identity (person, employeeID), value .person in Persons;

    Employees : Employee*;
    Persons : Person*;
}