To demonstrate a one-to-many relationship, we can associate Person with Hobby. This means that each hobby will belong to one and only one person (our people are hipsters who quickly move on at the first whiff of someone else enjoying what they enjoy).
All examples were run using the following test.
First, we can add a Hobbies property to Person and make no changes to any mapping files.
This creates the following migration:
After running the migration and our test, we see the following the database.
Next, we can try adding this relationship via the mapping files.
Unsurpisingly, this creates a migration that is identical to the one above.
While both of these work, Person_PersonId isn’t the column name I would like; PersonId would be ideal.
If we simply add PersonId to Hobby, we get the database structure that we would expect.
However, I have a personal preference for a more explicit approach. The following mapping will produce an identical migration with the added benefit of leaving nothing ambiguous.
If we want a Person navigation propert on our Hobby class, we can update the mappings accordingly, and once again end up with an identical migration.
Somewhat interestingly, if we choose to think of our data from the perspective of hobbies instead of people, we can add the mapping to the Hobby configuration and still achieve the same result by starting by using the HasRequired.WithMany instead of HasMany.WithRequired.
Coming from a background with string static type checking, I am often very happy with the loseness of JavaScript. Working with this TypeScript interface, an...
While building Aurelia applications, I have occassionaly made changes that cause the gulp build process to crash. It is very easy to add console logging to ...
Leave a Comment