Columns with name "Id" in JSon object causes System.ArgumentException in materialization

[jonnybee]

Using EF Core 7.0.0-rc.2.22472.11 (also same in v7.0.0-rtm.22504.12)

When JSon child object has a column named Id (f.ex of type Int) the materialization will throw:
System.ArgumentException: 'Expression of type 'System.Object' cannot be used for constructor parameter of type 'System.Int32'

Make these modifications to NewInEFCore7 sample in EntityFramework.Docs to reproduce the bug:

public class Commit
{
    public Commit(int id, DateTime committedOn, string comment)
    {
        Id = id;
        CommittedOn = committedOn;
        Comment = comment;
    }

    public int Id {get; private set; }
    public DateTime CommittedOn { get; private set; }
    public string Comment { get; set; }
}

// Update BuildPostMetadata method to send in an id as constructor parameter

    for (var j = 0; j < random.Next(3); j++)
     {
           update.Commits.Add(new(j+1, DateTime.Today, $"Commit #{j + 1}"));
     }

When you run the sample it will now throw ArgumentException here:

If I change Id to a property with { get; set; } and no parameters to the CTOR this exception is thrown:
System.ArgumentException: 'Expression of type 'System.Object' cannot be used for assignment to type 'System.Int32''

[ajcvickers]

@maumar Looks like it could be a problem with constructor binding for JSON objects in the materializer.

[jonnybee]

@maumar @ajcvickers Other properties of type int is deserialized OK - but when named Id will throw the ArgumentException. Could it be that Id is considered Key by convention for that type?

[ajcvickers]

@jonnybee Yes, I suspect that it is something to do with that.

[maumar]

owned types that are part of the collection have hard-coded ordinal key named "Id" of type int. Related issue: #28594

[maumar]

we should at least throw in validation until flexible ordinal key is implemented

[ajcvickers]

Note from triage: we should investigate if this is a materialization bug separate from #28594.

Possible workaround if the entity doesn't need the property to be called Id but Id is required in the JSON:

modelBuilder.Entity<Customer>()
    .OwnsOne(customer => customer.Contact, b =>
    {
        b.ToJson();
        b.OwnsMany(e => e.PhoneNumbers, b =>
        {
            b.Property(e => e.Key).HasJsonPropertyName("Id");
        });
    });

[maumar]

the problem comes from the fact that the Id property is considered to be a key.
In case of JSON entity each property is either column access (in case of key - we project the key column and access value based on that column index) or JsonElement.TryGetProperty (in case of normal JSON property). In this case Id column is considered to be a key, so we try to access it based on index (which isn't there) and hence the bug.

There doesn't seem to be a separate materialization bug, apart from #28594.

[johnatanstanley]

Hi, I'm also facing the same (or very similar) problem when a property is like:

public int [CLASSNAME]Id {get; set; } // Like "CommitId" in the first example of this post

If I'm not mistaken, entity use this nomenclature to generate reference between classes, so may be is "reserved" too.

[ajcvickers]

Notes from triage:

• It should be possible to have a property called "Id" that is not the ordinal key.
• Being able to explicitly map the key (Add support for persisting key properties on JSON-mapped entity types #28594) is also important, but different from this issue.

[Tizioincognit0]

• It should be possible to have a property called "Id" that is not the ordinal key.

Is there a way to have this feature on EF 7.0.8?

[thomas-darling]

According to the Npgsql docs, they've deprecated their support for .HasColumnType("jsonb"), which worked perfectly, in favor of .ToJson() - which won't work for us until this is fixed, as we just got blocked by #32360.

Please prioritize fixing this - it's been open for more than a year already...

[haslingerm]

I ran into this today as well and it took me quite some time to figure it out (found this issue only after having identified the root cause). If this can't be fixed soon I'd suggest adding a warning to the documentation at least.

[btecu]

Just ran into this issue and spent a couple of hours until I got to this ticket.
A warning would be useful but even better fixing the issue.

[oleg-varlamov]

I also encountered this problem today. Microsoft writes everywhere about good JSON support in the EF, but in fact we have many problems that prevent the use of JSON in real applications. We are waiting for a solution from the EFCore team.

[roji]

@ajcvickers didn't this go into rc2 as opposed to rc1 (the milestone)?

[andreyerick]

Thx for the example @sclarke81. For anyone else still having trouble: the workaround doesn't seem to work if you're using No-Tracking queries, it throws an exception "shadow properties cannot be preserved when attempting to SaveChanges".

[GaetanVigner]

Hello, thx for the fix, when can we expect to see a RC2 Nuget ?

[roji]

@GaetanVigner in around a month,