This is a real edge case, but if nothing else reporting it may help someone else save time down the road.
For reasons that couldn't possibly matter less, we've got a couple of models that look similar to:
public abstract class BaseModel
{
[Key]
public Guid Id { get; set; }
}
public class AuditInstance : BaseModel
{
[Key]
public new int Id { get; set; }
}
The idea being that guids are nice for most things, especially if they'd be used in a URL, but for a table that's just logging things that have happened the speed, storage, and ease of letting EF and SQL handle an auto-incrementing integer is preferable.
When GraphDiff tries to process one of these AuditInstance entities you'll get an exception: Ambiguous match found. that originates in EntityManager:GetPrimaryKeyFieldsFor on line 86. metadata.KeyMembers will include the one correct reference ("Id"), but the call to entityType.GetProperty fails because there are technically two properties with that name.
In our case the fix was simple... just take the Guid from the BaseModel. Still, it'd be nice if we didn't have to change our schema.
This is a real edge case, but if nothing else reporting it may help someone else save time down the road.
For reasons that couldn't possibly matter less, we've got a couple of models that look similar to:
The idea being that guids are nice for most things, especially if they'd be used in a URL, but for a table that's just logging things that have happened the speed, storage, and ease of letting EF and SQL handle an auto-incrementing integer is preferable.
When GraphDiff tries to process one of these
AuditInstanceentities you'll get an exception:Ambiguous match found.that originates inEntityManager:GetPrimaryKeyFieldsForon line 86.metadata.KeyMemberswill include the one correct reference ("Id"), but the call toentityType.GetPropertyfails because there are technically two properties with that name.In our case the fix was simple... just take the Guid from the BaseModel. Still, it'd be nice if we didn't have to change our schema.