The ORM Foundation

 Hello,

I am able to get automatic definitions of classes in simple model in C#. However, so far I have had less luck when using subtypes in my models. For example, suppose I have the following simple model of different kinds of languages:

Now, if I open the "ORM Generator Selection" window, select PLiX_Implementation and PLiX_Support, I get C# files containing the definition of the class Language, containing the two properties Name and LanguageType. However, classes for the two entities ProgrammingLanguage and NaturalLanguage are not created. Their fiels are added to the sql schema, though, e.g. for MS SQL I get this definition:

CREATE SCHEMA ORMModel1
GO

GO


CREATE TABLE ORMModel1."Language"
(
    languageId INTEGER IDENTITY (1, 1) NOT NULL,
    name NATIONAL CHARACTER VARYING(MAX) NOT NULL,
    languageType NATIONAL CHARACTER(1) CHECK (languageType IN (N'P', N'N')) NOT NULL,
    naturalLanguageNumber INTEGER CHECK (naturalLanguageNumber >= 0),
    programmingLanguageYear INTEGER,
    CONSTRAINT Language_PK PRIMARY KEY(languageId)
)
GO


GO

Now what I would like to have is C# definitions for my two subclasses, and, if possible, have the system automatically create objects of the right type when I query the database. Of course for this to work, I have to specify somewhere how to discriminate between ProgrammingLanguage and NaturalLanguage objects (something like "each ProgrammingLanguage is a Language that is of type 'P'"). Can this be done in a formal way in NORMA, so that it can automatically create the correct types of objects when reading the database?

 Henrik

Regarding the relational database schema, by default NORMA absorbs functional fact types played by subtypes back into the supertype (in this case, Language). You can arrange for the mapping to generate separate tables for the subtypes by changing the absorption choice to "separate" (e.g. see the section on Subtype mapping Options in NORMA Lab 8).

Regarding the C# generation, Matt can likely provide the best advice on that.

Cheers

Terry

Terry,

Regarding non-exclusive subtypes and role subtypes, these reflect the differences between subtyping in ORM2 and in typical O-O languages. I've managed to use Ruby's flexiblity to get something very close to multiple inheritance in a language that doesn't support it. In some cases non-exclusive subtyping can be handled through interfaces in languages like Java, C#, but in general, I don't know of any language (short of Smalltalk and its ilk) where ORM2's full model of subtyping can be handled.

Do you have a position on how these features of ORM2 should be mapped to existing O-O languages? It seems to me to present a significant impediment to its adoption. Perhaps we need a new fact-oriented programming language?

OK, thank you.

I've read the relevant pages of NORMA Lab tutorials, but unfortunately they aren't very helpful for me, since they keep referring to properties that don't exist in my NORMA version (just installed the very latest VS2010 edition a few minutes ago). For example, in this case it refers to the property "AbsorptionChoice", my properies window does not contain this property, or anything like it. Neither can I find a property named "DerivationRule" (used in another NORMA Lab). The available properties I get in the Properties window when selecting, e.g.,NaturalLanguage, are:

DerivationNote

DisplayRelatedTypes

ExpandRefMode

InformalDescription

IsIndependent (grayed out)

IsPersonal

IsValueType (grayed out)

Name

Note

ObjectifiedFactType

RefMode

So, does this mean that the NORMA Lab documents are made with an earlier version of NORMA? If so, where can I find the absoption option in the newest version?

Thank,

Henrik

Hi Henrik,

The "Absorption Choice" only appears when you have used the "Extension Manager" to turn on the "Relational View".

The "DerivationRule" is now called "DerivationNote". (Changed because the "rule" feature does not yet generate code so its only a note) 
If you enter a rule into the "DerivationNote" property a second property appears called  "DerivationStorage" with four options in a drop down list.

Ken

 Hi Clifford

 I agree with you that the class system in typical OO languages does not properly model conceptual typing. Classes are basically factories, not types, and an instance can't leave the factory that created it, unlike role types (e.g. consider an object migrating from the role type Applicant to Employee). Moreover, most OO languages don't support multiple inheritance, as least not in a conceptual fashion.

 To implement role subtypes in OO languages, some options are to remodel (e.g. use a status fact type instead), use a 1:1 association instead of a true subclass-superclass relationship, or use interfaces instead. Similarly for multiple inheritance, you can replace some subclasses by interfaces or use plain associations.

Hopefully some day someone will invent a practical programming language that is fact-oriented. LogicBlox's extended datalog language is getting close to realizing this hope.

Cheers

Terry

Terry Halpin:

an instance can't leave the factory that created it

Interestingly Javascript does make this possible; you can change an instance's "prototype". But it's still associated with only one prototype having no MI, so can't handle non-exclusive subtyping explicitly. Practically however, the prototype of an object matters little, and you can dynamically add or remove methods (corresponding to roles of added or removed subtypes) so Javascript is quite a reasonable candidate for a truly fact-oriented language.

With the advent of Google's blazing-fast V8 interpreter and the node.js server platform built on it, it's been catapulted into the mainstream as a serious development language too. I'll have to look into generating it from CQL :)