ResourceObjectAdapter converts relationship but does not set foreign key

[bjornharrtell]

SUMMARY

A resource model might have explicitly mapped foreign keys, like the Post entity at https://learn.microsoft.com/en-us/ef/core/modeling/relationships#mapping-relationships-in-ef-core. Typically both the foreign key and and navigation property are expected to be not null if the relationship is required.

When ResourceObjectAdapter converts from document to entity it sets navigation property from relationship but not foreign key property. It will be peristed ok but is unexpectedly null until retrieved from database again. This can cause confusement when for example extending EntityFrameworkCoreRepository and iteract with the entity before persisting. I have encountered this when creating entities with relations using atomic operations, not sure it is relevant elsewhere.

Would it make sense to resolve foreign key mapping and set it in this case?

VERSIONS USED

• JsonApiDotNetCore version: 5.9.1
• ASP.NET Core version: 8.0.21
• Entity Framework Core version: 9.0.10
• Database provider: Npgsql.EntityFrameworkCore.PostgreSQL 9.0.4

[bkoelman]

From what I understand, foreign key properties in entities are a left-over from the days that nullable reference types didn't exist. I've never needed to define them since. They are automatically created by EF Core as shadow properties when not explicitly defined. The advantage of that is they are always compatible with the navigation. For example, when refactoring a required to-one navigation to an optional one, but you forget to make the foreign key property also nullable, or the other way around, weird things happen. Explicit foreign key properties are always redundant in EF Core, as far as I'm aware.

In JSON:API, the concept of a foreign key does not exist. I believe that their recommendation is that any Id properties, other than the resource identity, should not exist and be modeled as relationships instead. The endpoints and the query string parameters in the spec are powerful enough to deal with that.

From an architectural perspective, ResourceObjectAdapter is storage-agnostic, so it knows nothing about EF Core or foreign keys, in contrast to EntityFrameworkCoreRepository, hence its name.

Why do you want to explicitly define FK properties in models, and then also publicly expose them via JSON:API?

[bjornharrtell]

It's deep rabbit hole to discuss, but the value I see in explicit foreign keys is that they are available even if the relationship is not included and cheap to query. I actually find it a bit jarrying that we now use a not null reference type as navigation property to configure a required relation at the "one" side but if I don't include it in a query it will be null in runtime. To me, it would actually make more sense to define model configuration with an explicit not nullable value type as foreign key and the navigation property as nullable to reflect that it can be null at runtime.

[bkoelman]

It's deep rabbit hole to discuss, but the value I see in explicit foreign keys is that they are available even if the relationship is not included and cheap to query.

Doing so circumvents the security model. A user who isn't permitted to query or update the relationship can now do so anyway via the foreign key directly. I've created a table with 100_000 Person rows in the JADNC sample and assigned the last one as the owner of the first todo item. I can't spot a performance difference on Postgres between:

GET /api/todoItems/1?include=owner&fields[people]=id

and:

GET /api/todoItems/1

Both SQL statements execute in ~50 msec. This is because EF Core auto-creates an index on foreign key columns. What do you mean by "cheap to query"?

I actually find it a bit jarrying that we now use a not null reference type as navigation property to configure a required relation at the "one" side but if I don't include it in a query it will be null in runtime. To me, it would actually make more sense to define model configuration with an explicit not nullable value type as foreign key and the navigation property as nullable to reflect that it can be null at runtime.

This is how JSON:API works, and I don't understand why that is problematic. Any field (attribute or relationship) not retrieved will not appear in the response. And any field that does not appear in the request will not be assigned/updated. This applies both to a non-nullable attribute (such as string LastName or [Required] int? VoteCount) and a required to-one relationship.

[bjornharrtell]

I haven't come up with any arguments against yours regarding exposing them in JSON-API and perhaps doing so is misguided on my part.

But I still think it can be valuable to have them explicitly in EF Core. Examples I can think of at the moment are:

• You might want to create indexes combining the FK with others which require a string reference to the hidden shadow FK if not explict.
• In a data migration application (from a legacy schema to new code first) you might have the need to import foreign keys directly.

But so, these are EF Core concerns and pretty far from making JSON-API aware of this and since I can't argue that it makes sense to do so I will close this question. Thanks @bkoelman for the discussion. :)