Mixing
EF Core - Creating two navigation properties mapped to a single inverse property
I have the following entities set up.
public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}
public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}
A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.
I can set this up in EF Core 2.1 using the following config:
modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();
This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.
Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.
However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.
- Is this possible to configure these entities using just the two
(CarIdFrontWheel & CarIdRearWheel) foreign keys? - Should I instead just accept the existence of the CarId foreign key?
- Or, are there some changes I can make to my model to help this situation?
c# .net entity-framework ef-core-2.1
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
|
show 5 more comments
I have the following entities set up.
public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}
public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}
A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.
I can set this up in EF Core 2.1 using the following config:
modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();
This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.
Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.
However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.
- Is this possible to configure these entities using just the two
(CarIdFrontWheel & CarIdRearWheel) foreign keys? - Should I instead just accept the existence of the CarId foreign key?
- Or, are there some changes I can make to my model to help this situation?
c# .net entity-framework ef-core-2.1
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
1
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would haveonecollection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
– JohnB
Nov 20 '18 at 0:16
1
the Wheel class can have a nav property back to aCar(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPositionProperty (Front-Left) or similar...
– JohnB
Nov 20 '18 at 0:21
1
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
1
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
1
also think about how developers will need to access data: egcar.Wheels.Front();orcar.Wheels.FrontLeft();
– JohnB
Nov 20 '18 at 0:31
|
show 5 more comments
I have the following entities set up.
public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}
public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}
A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.
I can set this up in EF Core 2.1 using the following config:
modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();
This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.
Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.
However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.
- Is this possible to configure these entities using just the two
(CarIdFrontWheel & CarIdRearWheel) foreign keys? - Should I instead just accept the existence of the CarId foreign key?
- Or, are there some changes I can make to my model to help this situation?
c# .net entity-framework ef-core-2.1
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
I have the following entities set up.
public class Car
{
public int Id { get; protected set; }
public HashSet<Wheel> FrontWheels { get; set; };
public HashSet<Wheel> RearWheels { get; set; };
}
public class Wheel
{
public int Id { get; protected set; }
//public Car Car { get; set; }
public double Diameter { get; set; }
public double Width { get; set; }
}
A Car has Wheels. It interacts with the fronts and rears very differently and therefore they are held in different collections. A wheel by itself is neither a front or a rear (it could be either), it is only through its association with the car that it is given a position on the car.
I can set this up in EF Core 2.1 using the following config:
modelBuilder.Entity<Car>().HasMany(car => car.FrontWheels).WithOne();
modelBuilder.Entity<Car>().HasMany(car => car.RearWheels).WithOne();
This creates a Wheel table with two nullable fk columns, CarIdFrontWheel & CarIdRearWheel. I understand why it creates two columns and why they're nullable (only 1 fk column will be populated for each Wheel row, and that column describes the position on the car). This schema describes the situation and I am happy with that.
Now the problem starts when I want to add back in the commented out inverse navigation property - so that I can navigate from a Wheel to it's connected Car. However I configure it, EF always wants to add another fk named CarId to the Wheel table to map back to a Car. I understand why it needs to do this - Otherwise I'm attempting to ask one property (Wheel.Car) to partake in two relationships. Both fks could point to a different Car id, etc.
However, what I am asking seems logically reasonable from an entity relationship point of view. If we were writing this data access manually, we could make the schema work without this unnecessary (somewhat de-normalized) 3rd foreign key.
- Is this possible to configure these entities using just the two
(CarIdFrontWheel & CarIdRearWheel) foreign keys? - Should I instead just accept the existence of the CarId foreign key?
- Or, are there some changes I can make to my model to help this situation?
c# .net entity-framework ef-core-2.1
c# .net entity-framework ef-core-2.1
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
asked Nov 20 '18 at 0:11
MartynMartyn
75221126
75221126
1
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would haveonecollection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
– JohnB
Nov 20 '18 at 0:16
1
the Wheel class can have a nav property back to aCar(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPositionProperty (Front-Left) or similar...
– JohnB
Nov 20 '18 at 0:21
1
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
1
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
1
also think about how developers will need to access data: egcar.Wheels.Front();orcar.Wheels.FrontLeft();
– JohnB
Nov 20 '18 at 0:31
|
show 5 more comments
1
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would haveonecollection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...
– JohnB
Nov 20 '18 at 0:16
1
the Wheel class can have a nav property back to aCar(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPositionProperty (Front-Left) or similar...
– JohnB
Nov 20 '18 at 0:21
1
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
1
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
1
also think about how developers will need to access data: egcar.Wheels.Front();orcar.Wheels.FrontLeft();
– JohnB
Nov 20 '18 at 0:31
1
1
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have
one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...– JohnB
Nov 20 '18 at 0:16
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have
one collection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...– JohnB
Nov 20 '18 at 0:16
1
1
the Wheel class can have a nav property back to a
Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...– JohnB
Nov 20 '18 at 0:21
the Wheel class can have a nav property back to a
Car (CardId). And to determine which actual tyre the wheel is one may also imagine it having a Position Property (Front-Left) or similar...– JohnB
Nov 20 '18 at 0:21
1
1
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
1
1
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
1
1
also think about how developers will need to access data: eg
car.Wheels.Front(); or car.Wheels.FrontLeft();– JohnB
Nov 20 '18 at 0:31
also think about how developers will need to access data: eg
car.Wheels.Front(); or car.Wheels.FrontLeft();– JohnB
Nov 20 '18 at 0:31
|
show 5 more comments
0
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384432%2fef-core-creating-two-navigation-properties-mapped-to-a-single-inverse-property%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53384432%2fef-core-creating-two-navigation-properties-mapped-to-a-single-inverse-property%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
i would approach this slightly differently. my gut feeling is that a wheel should have a fk field for WheelPostion (Front/Rear). I would have
onecollection of Wheels / vehicle. (You could implement a business rule to validate you have the number of wheels required and and the correct wheel types.) just my 2 cents...– JohnB
Nov 20 '18 at 0:16
1
the Wheel class can have a nav property back to a
Car(CardId). And to determine which actual tyre the wheel is one may also imagine it having aPositionProperty (Front-Left) or similar...– JohnB
Nov 20 '18 at 0:21
1
EF (Core) requires (allows) one navigation property to be mapped to one and only one relationship. Starting from here, it's up to you what is acceptable - 2 or more FKs, or single collection with property (sort of a discriminator) at the many side. I would personally go the second way.
– Ivan Stoev
Nov 20 '18 at 0:25
1
Yes, a property of a wheel on a car can be thought of as having a position. i see no major drama with that. So it would be as complex as you want to go. to see how deep you can go => schema.org/Car
– JohnB
Nov 20 '18 at 0:28
1
also think about how developers will need to access data: eg
car.Wheels.Front();orcar.Wheels.FrontLeft();– JohnB
Nov 20 '18 at 0:31