Database first development, Target per entity hierarchy inheritance.

Let's say I have a table SomeTable like: Id (PK) Field1 OtherTableId (FK, nullable) Discriminator

I create a super-type without FK, like:

Supertype table

Id (PK) Field1 Discriminator

And subtype table with this additional field? OtherTableId (FK, nullable)

Here is what I do. Create sub type. Remove OtherTableId field from super-type and map it to sub-type. That's fine. But the relationship is stuck at super-type. I remove it and manually recreate it at sub-type. That works but it could be better done. 1. When removing the field (from super-type) the matching relationship could be automatically removed. It works the other way round. 2. When mapping a field into sub-type the relationship could be automatically created. 3. Is it possible to have a Many-1 instead of Many to 0...1 on sub-type? I get warnings that an int is mapped on nullable field when Many-1 is enforced in designer. OtherTableId has to be nullable in database due to the hierarchy.

Which Designer version are you using?

As for the Many-1, I think a warning is fair in this situation, as the field is nullable in the database, right?

Walaa wrote:

Which Designer version are you using?

As for the Many-1, I think a warning is fair in this situation, as the field is nullable in the database, right?

Hi Walaa,

Version is "December 11th, 2012". Fair - well, depends on how you look at it. The database field is nullable only because of the inheritance but from the logical perspective (in specific sub-type) it shouldn't be nullable.

So it doesn't prevent it, but just displays a warning, is this causing a problem?

Walaa wrote:

So it doesn't prevent it, but just displays a warning, is this causing a problem?

Yep.

The warning is there because in theory the row might contain a NULL value, due to data which is inserted with code outside your own code. It's not an error, but a warning: the warning will let you know that IF the data contains NULLs, it will crash your application. Your code can't assure that there aren't NULL values.

Otis wrote:

The warning is there because in theory the row might contain a NULL value, due to data which is inserted with code outside your own code. It's not an error, but a warning: the warning will let you know that IF the data contains NULLs, it will crash your application. Your code can't assure that there aren't NULL values.

I understand all this, it is just that warning is redundant for me. Perhaps there could be a way to disable certain warnings?

Isn't that asking for problems, i.e. that one time when you should have looked at the warnings but didn't (because they're hidden)?

The warnings are there because the user has to be aware of the problem of a given field, as the designer can't know whether it's a known thing (for that field!) or that the user made an error/mistake.

If you have a lot of warnings related to unmapped tables/views, you can change that feature in the project settings, which will trim down the list of warnings a lot.