Implement One-To-One API (with FK support)

[alexmurari]

I'm almot certain that it´s never gonna be implemented here, but, well... let´s consider the possibility.

Judging by the One-To-One API implementation in EF Core (when it was still EF 7 back in 2014) made by @ajcvickers , the changes required to create an OneToOne API ain´t that scary. Of course the codebase here is different from the EF Core and the implementation can be different and more difficult. But the advantages of having such implementation can justifiy the work and make EF6 continue to grow. Besides this is an feature largely requested by the community.

What you guys think, worth trying to create an One-To-one API? If you guys give your opinion and point me to the right bits I can try to implement it and create an PR.

Thanks!

[divega]

EF Triage: @MurariAlex we discussed this and we believe it would really help a lot if you could come up with concrete code examples of things you can do with the EF Core relationship API that you cannot do with the existing EF6 relationship API. Once you have identified specific functionality that is missing we can move on to talk about the value of adding them, e.g. linking to examples of where this has been request by the community or examples how it would help you in your work.

[alexmurari]

Thanks for the reply, @divega.

Consider this example.

public class Address 
{
      public int Id { get; set; }
      // Other properties...
}

public class Customer
{
      public int Id { get; set; }
      public int AddressId { get; set; }

      public virtual Address Address { get; set; }
}

public class Employee
{
      public int Id { get; set; }
      public int AddressId { get; set; }

      public virtual Address Address { get; set; }
}

The Customerand Employee table points to the Address table using the AddressIdFK, this is a must have in my scenario because other clients consume this database through pure SQL and the address is fetched through joining the tables using the AddressId FK.

It would be perfectly normal (and in my case necessary) to do something like this:

modelBuilder.Entity<Customer>()
            .HasOne(p => p.Address)
            .WithOne()
            .HasForeignKey<Customer>(b => b.AddressId);

Or, like you do already in EF Core:

modelBuilder.Entity<Customer>().OneToOne(a => a.Address).ForeignKey<Customer>(a => a.AddressId);

This a must have in my scenario.

Regarding the request, there are several SO threads of people bemoaning the absence of this feature and this User Voice Thread from 2010 requesting Unique Constraint support that is nothing less than the support to have a FK that is an unique constraint that is not a PK.

https://stackoverflow.com/questions/14807383/will-one-to-one-foreign-key-associations-be-supported-in-ef-v-next https://stackoverflow.com/questions/10108160/entity-framework-code-first-setting-up-one-to-one-foreign-key-association-usin https://stackoverflow.com/questions/37337472/ef-one-to-one-or-zero-relationship-with-custom-foreign-key-column-name

An ugly hack to make it work today. http://hudosvibe.net/post/entityframework-one-to-one-with-foreign-keys

Thanks for considering this.

Alex.

[ajcvickers]

Note for triage: The underlying architecture for EF6 does not support 1:1 relationships that are not PK to PK where the FK is mapped to a CLR property. So the example above would not be supported without a huge amount of work. The only thing we might be able to make work with API changes would be an independent association where the FK is not a PK, but I have a vague recollection that there are some restrictions even on that. And it would also promote IA's, which comes with its own issues.

[divega]

EF Team Triage: We believe the current fluent API for EF6 matches the EF6 functionality better.