issues with schema for polymorphic mappings

Discussion of open issues, suggestions and bugs regarding Entity Developer - ORM modeling and code generation tool
Post Reply
Posts: 148
Joined: Tue 13 Dec 2011 22:58
Location: Ithaca, NY

issues with schema for polymorphic mappings

Post by mindplay » Wed 25 Jan 2012 18:24

I've uncovered some problems with polymorphic mappings.

Here's a sample project I created to demonstrate some of the issues: ... I2NDIyMDgy

In this example, 3 types derive from an abstract Message base type: Fax, Letter and Email.

I'm using a table-per-hierarchy mapping, and most of the problems are related to mapping these types to the same table.

The generated schema looks like this:

Code: Select all

CREATE TABLE dbo.Messages (
   Subject VARCHAR(255) NOT NULL,
First problem:

The Letter and Email types both have a Subject property, and these are mapped to the same column. Both are Nullable=False.

The column is generated as VARCHAR(255) NOT NULL, which is incorrect - it won't work, because the Fax type doesn't have a Subject property.

The Subject properties on Letter and Email are not nullable, and for those two entity types, the generated mappings are correct, in that we do want NH to prevent inserting NULL-values for that property, for those two types.

But the constraint cannot be enforced at the schema-level, as this makes it impossible to insert a Fax entity - which will always violate the NOT NULL constraint, as it does not have this property.

In other words, the Subject column should be generated as nullable - even if entities that do have this property should be mapped as not-nullable.

Second problem:

The Fax.Message, Letter.Text and Email.HTML properties are all mapped to the same column: Body.

One of these properties, Letter.Text, are flagged as Column.Unicode=True.

But the generated schema is VARCHAR(MAX), not NVARCHAR(MAX).

I think the problem here is really more of a general user-interface problem than anything else. ED does not seem to have an awareness of multiple properties mapping to the same column.

To use a simpler example, take Letter.Subject and Email.Subject - if you set the Column.Unicode property on either of those, it does not propagate to the other, although these are actually mapping to the same column.

Bottom line, if any property is mapped to the same column, setting any of the Column-settings on the model, ought to propagate to the Column-settings of other properties mapped to the same physical column.

Proposed Solution:

I believe the second problem can be solved most simply at the user-interface level, since, presumably, you already have some logic in the schema-generator that enables it to "survive" conflicting column-settings, and still generate valid schema.

Ideally, you should not be permitted to make conflicts - at the very least, these should report as conflicts when you validate the model.

But ideally, the user-interface should not let you create conflicts, by propagating any changes made to Column-settings to the relevant Column-settings of properties, when they overlap at the schema-level.

If implemented this way, there are two important cases to take into account: adding a new property that overlaps with another existing property; and changing the Name in the Column-settings of an existing property, causing it to overlap with another existing property. In both cases, the Column-settings would overwrite the Column-settings of other properties already mapped, which is probably not what the end-user wants.

Assuming that ED would help you keep the Column-settings of any other existing overlapping properties consistent, you can safely copy the Column-settings from any of those - it doesn't matter which one.

The important point here, is you don't want a new property (or a Column.Name change) to overrule already existing Column-settings of any overlapping properties - rather, you want the pre-existing Column-settings to be "imported" to the new (or updated) column from an existing one. (after doing so, it is safe to propagate any further changes to the Column-settings from the new/updated property to the rest of the model.)

One last important thing to note, is that this behavior should apply only to table-per-hierarchy mappings - it must not apply to other types of inheritance-mappings, since those do not result in overlapping column-mappings.

Devart Team
Posts: 7974
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Fri 27 Jan 2012 12:04

Thank you for your report. We have reproduced and are investigating the issue.

Devart Team
Posts: 7974
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Sat 03 Mar 2012 14:56

  • The merging of crossing columns in Table Per Hierarchy (TPH) when generating schema is added
  • The warnings if merging of crossing columns in Table Per Hierarchy (TPH) when generating schema cannot be done correctly is added
  • The bug with calculation of NOT NULL columns in Table Per Hierarchy (TPH) when any of the descendants does not have such column is fixed
We will post here when the corresponding build of Entity Developer is available for download.

Devart Team
Posts: 7974
Joined: Thu 14 Aug 2008 12:44

Post by Shalex » Fri 16 Mar 2012 17:41

New version of Entity Developer 4.3 is released!
It can be downloaded from (trial version) or from Registered Users' Area (for users with active subscription only).
For more information, please refer to .

Post Reply