Devart Forums

I have a table, Contacts, and a table, Login.

A Contact may or may not have a Login.

I'm using 64 bit IDs generated in the service rather than in the DB, so in theory, I should be able to use the same IDs for both tables.

The problem is that Entity Developer models this as a 1:1 relationship, which kind of makes sense, since it has no way of knowing which of the two tables is the "main" one. So the navigation property from Contact to Login -- which should be nullable -- isn't.

I could have Login inherit from Contact instead, but that's not quite what I want, as it won't produce a navigation property.

And in theory, I could just have a foreign key on Login as opposed to a primary key, but EF doesn't condone that, and ED doesn't allow it.

Is there a way around this?

Thanks!

Actually, it doesn't seem possible to make a one to zero/one relationship unless the foreign key is nullable.

I must be missing something obvious...

You are working with EF6, aren't you? Refer to viewtopic.php?f=32&t=35595.

EF Core. This seems to have worked, but I'm still running into problems getting nullable reference types (specifically, 1-0 keys) to actually be nullable, even with it turned on in the template.

With EF Core, create a one-to-one association, map its FK end to the property with Nullable=True to make the association 1-0..1.

I'm trying to make this a 0..1 with the Login being optional. Neither the FK ContactID nor the navigation property are nullable in this situation, and I can't make ContactID a non-PK without it complaining (which makes sense).

Ideally, I'd like not to make a LoginId FK in Contact. I'm able to do this in code, but I don't seem to be able to in ED.

We will investigate the behavior of the Constrained option in Association Editor of EF Core Model. Please specify the exact version of your EF Core.

As a workaround, please redesign your Login table to create LoginId (PK) and ContactId (FK, Nullable=True).

We're using EF Core 5.0.9.

Thanks!

We will notify you about the results of our investigation.

I just realized that it doesn't make any of the navigation properties nullable, even if it's based on a FK (i.e. not an inverse property).

• The bug with code generation for the Constrained option of Association Editor in the case of 0..1 -> 1 association in EF Core Model is fixed
• The representation of one-to-one association with non-nullable properties on both ends is changed from 1 -> 1 to 0..1 -> 1 on a diagram in EF Core Model

We will notify you when a new public build of Entity Developer is available for download.

Thanks!

Has this been addressed? It looks like it's still treating the navigation property as non-null.

Edit: Actually, even for a normal many-to-one navigation property with a nullable ID, the navigation property ends up non-nullable.

Sorry for the late response. We are processing your request.