We Keep Coding

EF Core 2.2.6: Unable to map 2 foreign keys to the same table

I am having issues trying to map two fields that are foreign keys into the same table. The use case is for a modifier and creator. My class already has the Ids, and then I wanted to add the full User object as virtual.
I am using a base class so that each of my tables have the same audit fields:
public class Entity
{
public long? ModifiedById { get; set; }
public long CreatedById { get; set; } = 1;
[ForeignKey("CreatedById")]
public virtual User CreatedByUser { get; set; }
[ForeignKey("ModifiedById")]
public virtual User ModifiedByUser { get; set; }
}
The child class is very simple:
public class CircleUserSubscription : Entity
{
[Required]
public long Id { get; set; }
public long SponsorUserId { get; set; }
[ForeignKey("SponsorUserId")]
public virtual User User { get; set; }
public long TestId { get; set; }
[ForeignKey("TestId")]
public virtual User Test { get; set; }
}
This is a standard junction table.
When I try to generate the migration, I am getting errors that I don't understand fully.
Unable to determine the relationship represented by navigation property 'CircleUserSubscription.User' of type 'User'. Either manually configure the relationship, or ignore this property using the '[NotMapped]' attribute or by using 'EntityTypeBuilder.Ignore' in 'OnModelCreating'.
I tried what this answer had, but the code is basically the same: https://entityframeworkcore.com/knowledge-base/54418186/ef-core-2-2---two-foreign-keys-to-same-table
An inverse property doesn't make sense since every table will have a reference to the user table.
For reference, here is the User entity:
public class User : Entity
{
public long Id { get; set; }
public string Username { get; set; }
public string Email { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
I am hoping you all can help me out, TIA :)
EDIT: One thing to note, all of this worked fine when the entity class was as follows:
public class Entity
{
public long? ModifiedById { get; set; }
public long CreatedById { get; set; } = 1;
}
It was only after I added the entity that things went awry.

Using nullable for Foreign Key in Entity Framawork

I use EF Code First approach in an ASP.NET MVC project and I have PK-FK relations on several entities as shown below:
public class Staff
{
public int Id { get; set; }
//Foreign key for Project
public int ProjectId { get; set; }
public virtual Project Project { get; set; }
}
public class Project
{
public int Id { get; set; }
public string Name { get; set; }
public virtual ICollection<Staff> Staffs { get; set; }
}
On the other hand, sometimes there is a need to use nullable FK values and in that case I create dummy record as N/A as FK is required property that seems to em ugly :( I know I can easily use nullable value for the related FK property, but I am not sure if it is a good approach or not. And what is the pros and cons using this approach (I know a pros of required FK : Data integrity :)
Secondly, should I use 0 or null value for the nullable FK? Why?

Adding a dummy record is not right, the correct approach here is to use an int? for the foreign key relation, see here:
If the data type of GradeId is nullable integer, then it will create a
null foreign key.
public class Student
{
public int Id { get; set; }
public string Name { get; set; }
public int? GradeId { get; set; }
public Grade Grade { get; set; }
}
The above code snippet will create a nullable GradeId column in the
database because we have used Nullable<int> type (? is a shortcut for
Nullable<int>)
An alternative approach would be removing ProjectId from the staff (Convention 3 in the above document):
public class Staff
{
public int Id { get; set; }
public virtual Project Project { get; set; }
}
public class Project
{
public int Id { get; set; }
public string Name { get; set; }
public virtual ICollection<Staff> Staffs { get; set; }
}

Entity Framework One-to-Many AND a One-To-One relationship

I currently have a data model where a property can have multiple property images:
public class Property
{
public int ID { get; set; }
public string Name { get; set; }
public Guid PrimaryImageID { get; set; }
public ICollection<PropertyImage> Images { get; set; }
}
public class PropertyImage
{
[Key]
public Guid ID { get; set; }
public int PropertyID { get; set; }
public virtual Property Property { get; set; }
}
However, as you can see, i also want to enable a relationship so that a property can have ONE of those images assigned as a primary image.
I found an article here, that seems to use the Fluent API to configure it, but that's all fairly new to me, so i was wondering if it was possible to do this purely using Entity Framework?
What i REALLY want to achieve, is so that i can just call...
property.primaryimage.url
for example. If a user then wanted to change the primage image of a property, then i just change the PrimaryImageId field to the Guid of a different image
Many thanks

Personally, I wouldn't be messing around with EF to do this, the answer in the link you shared would pretty much agree with me. I would simply add another field to the PropertyImage class
public bool IsPrimaryImage {get;set;}
and just find the image based on the value set in that.
Sometimes the simplest solution is the best. You could end up with a convoluted solution in EF that does what you want but at the end of the day, would it really be better than just assigning true or false to a field?

First, you will add a "PrimaryImage" property to your Property class:
public class Property
{
public int ID { get; set; }
public string Name { get; set; }
public Guid PrimaryImageID { get; set; }
public virtual PropertyImage PrimaryImage { get; set; }
public ICollection<PropertyImage> Images { get; set; }
}
In your class where you inherit Entity's framwork DbContext, you can override the method OnModelCreating, which will lead you to:
protected override OnModelCreating(DbModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
}
Then, after the line base.OnModelCreating(modelBuilder), you can write:
modelBuilder.Entity<Property>().
.HasRequired(x => x.PrimaryImage)
.WithRequiredPrincipal();
modelBuilder.Entity<Property>().
.HasMany(x => x.Images)
.WithRequired(x => x.Property);
If this is what you want, then I believe this code allows you to have this property you need. Hope it helps!

If you need a Property to have a primary PropertyImage that can only be an image that is applicable to that Property, the emphasis needs to be switched:
You cannot set the primary Image for a Property until the images are entered and related to the Property to begin with.
You can't add the images unless the Property exists to relate to.
So, you would need to have the PrimaryImage property nullable until later set.
While a PropertyImage relies on a Property, a Property does not rely on a PropertyImage, and so should not be a foreign key in it's record.
This means that the flag (boolean value) for PrimaryImage needs to be stored with the PropertyImage indicating which one of the images is the primary one.
Remove the PrimaryImageId from Property and place a property on the PropertyImage (IsPrimaryImage) to allow selection of the primary one.
You can handle the unique selection either via the UI or more properly with a Unique Constraint on the table.
public class Property
{
public int ID { get; set; }
public string Name { get; set; }
public ICollection<PropertyImage> Images { get; set; }
}
public class PropertyImage
{
[Key]
public Guid ID { get; set; }
public int PropertyID { get; set; }
public bool IsPrimaryImage { get;set; }
public virtual Property Property { get; set; }
}
It isn't good practice to try to structure the data and its relationships around the way you'd like to call a method in code.
You can still call the method the way you want and encapsulate any logic you may need inside.
Think along the lines of if there was a cascade delete applicable here to remove items that no longer have a parent item to relate to:
If you delete a Property, all related PropertyImages would be removed too - correctly so because they relied on that record existing.
If you delete the primary PropertyImage, then the Property would have to be deleted because the record it relates to no longer exists...
So to have your method call the way you would like, do something similar to this:
private void UpdatePrimaryImage(PropertyImage oldImage, PropertyImage newImage)
{
// Pass in the original primary PropertyImage and the new one obtained from the UI.
// Check that we do not have the same image, otherwise no change needs to be made:
if(oldImage.IsPrimary != newImage.IsPrimary)
{
oldImage.IsPrimary = false;
newImage.IsPrimary = true;
Update(oldImage);
Update(newImage);
SaveChanges;
}
}
And to retrieve the current primary image:
Property.PropertyImages.Where(p => p.IsPrimaryImage).Url

Try this:
public class Property
{
public int ID { get; set; }
public string Name { get; set; }
public Guid PrimaryImageID { get; set; }
[ForeignKey("PrimaryImageID")]
public virtual PropertyImage PrimaryImage { get; set; }
public ICollection<PropertyImage> Images { get; set; }
}
public class PropertyImage
{
[Key]
public Guid ID { get; set; }
public int PropertyID { get; set; }
[ForeignKey("PropertyID")]
public virtual Property Property { get; set; }
}

How to make proper code-first relations

I'm fairly new to Entity Framework and feel more in control using the Code-First pattern rather than DB-First.
I was wondering what is more preferred when it comes to programmatically setting up ForeignKey relations between the entities.
Is it better to declare a FK_ property in the class which relates to the another class or is it better to declare an IEnumerable<> property in the class that gets related to?
public class IRelateToAnotherClass
{
...
public int FK_IGetRelatedToByAnotherClass_ID { get; set; }
}
or
public class IGetRelatedToByAnotherClass
{
...
public IEnumerable<IRelateToAnotherClass> RelatedTo { get; set; }
}

It all depends on what type of relationships you want between your entities (one-to-one, one-to-many, many-to-many); but, yes, you should declare foreign key properties. Check out this site for some examples.
Here's a one-to-many for your two classes:
public class IRelateToAnotherClass
{
public int Id { get; set; } // primary key
public virtual ICollection<IGetRelatedToByAnotherClass> IGetRelatedToByAnotherClasses { get; set; }
}
public class IGetRelatedToByAnotherClass
{
public int Id { get; set; } // primary key
public int IRelateToAnotherClassId { get; set; } // foreign key
public virtual IRelateToAnotherClass IRelateToAnotherClass { get; set; }
}
and with some Fluent API mapping:
modelBuilder.Entity<IGetRelatedToByAnotherClass>.HasRequired<IRelateToAnotherClass>(p => p.IRelateToAnotherClass).WithMany(p => p.IGetRelatedToByAnotherClasses).HasForeignKey(p => p.Id);

If I understand what you're asking correctly, you'd want both. You want an int FK property and an object property to use as the navigation property.
The end result would look something like this:
public class Employee
{
[Key]
public int EmployeeID { get; set; }
[ForeignKey("Store")]
public int StoreNumber { get; set; }
// Navigation Properties
public virtual Store Store { get; set; }
}
public class Store
{
[Key]
public int StoreNumber { get; set; }
// Navigation Properties
public virtual List<Employee> Employees { get; set; }
}
If you haven't already, take a look at navigation properties and lazy-loading. Note that EF is clever enough to figure out that an int StoreID property corresponds to an object Store property, but if they are named differently (such as without the ID suffix), you must use the [ForeignKey] annotation.

EF Code first - Lazy Loading How to set up and access the joining table

public class Product
{
[Key]
public int Id { get; set; }
public string Name { get; set; }
public string Description { get; set; }
public decimal Price { get; set; }
public bool IsInStock { get; set; }
public string ImageUrl { get; set; }
public List<ProductOption> ProductOptions { get; set; }
public virtual Category Category { get; set; }
}
public class ProductOption
{
[Key]
public int Id { get; set; }
public string ProductOptionName { get; set; }
public string ProductOptionDescription { get; set; }
}
Now I know when your using Code First EF, so that the tables are created correctly. You need to do something like this.
modelBuilder.Entity<Product>().HasMany(p => p.ProductOptions).WithMany().Map(m =>
{
m.MapLeftKey("ProductId").MapRightKey("ProductOptionId").ToTable("SelectedProductOptionsInOrderedItem");
});
So....
Does this mean that if I do something like Product.ProductOptions I will be able to access all associated productoptions.
Is this the best way to set it up, or is there another way?

To enable lazy load and EF can create derived proxy types for your collection, that property should be declared this way:
public virtual ICollection<ProductOptions> ProductOptions { get; set; }
That should be enought. Other aspect is the mapping approach that you use. You choose fluent api, i prefer mapping by convention, but that is a matter of personal taste anyway.
Ok, Mapping by Conventions:
Is the ability of EF that from the name of entities and their properties along with their types, to map our model with the underlying data without providing any other information.
for example
public class Customer {
public long CustomerID {get; September;}
public string CustomerName {get; September;}
public Employee AssignedTo {get; September;}
}
With the previous model EF will map database with a table named Customer with:
. CustomerID bigint primary key column
. CustomerName nvarchar column
. Customer_EmployeeID foreign key to Employee table, with the datatype Corresponding to EmployeeID in that table.
You can read more Here