I have a DbContext with three tables. There is many-to-many connection between Items and Orders.
public virtual DbSet<Item> Items { get; set; }
public virtual DbSet<Order> Orders { get; set; }
public virtual DbSet<ItemOrder> ItemOrders { get; set; }
also I have a method for removing a record from ItemOrders.
public void RemoveItemFromOrder(ItemOrder itemOrder)
{
itemOrder.Item.Orders.Remove(itemOrder);
context.ItemOrders.Remove(itemOrder);
context.SaveChanges();
}
(this code was written by previous developer).
I need to understand, why can't I just remove itemorder from ItemOrders in the context? Why do I need also to remove itemOrder from collection of (item)orders in connected item?
Related
I have the following models:
class Item
{
public ICollection<string> GroupIds { get; set; }
// Introduced for EF only
public ICollection<Group> Groups { get; set; }
}
class Group
{
public ICollection<string> ItemIds { get; set; }
// Introduced for EF only
public ICollection<Item> Items { get; set; }
}
class Store
{
public ICollection<Item> Items { get; set; }
public ICollection<Group> Groups { get; set; }
}
Store contains all Items and all Groups, but every Item may be related with one or multiple Group and every Group may be related with one or multiple Item.
How I can configure many-to-many relationship between Item and Group to load only GroupIds and ItemIds, but not objects itself?
I am new to entity framework and I am using code first approach to create entities using TPT inheritance.
My requirement is to create the entities as per the attached diagram where ID is PK for Customers table and FK for the AddressDetails and ContactDetails table. Based on the keys I also need to create the association and navigation properties for the entities. Table Diagram
In my code I have created entities as
public class Customer
{
[Key]
public int Id { get; set; }
public string Name { get; set; }
public int ZipCode { get; set; }
public virtual ContactDetails ContactDetails { get; set; }
public virtual AddressDetails AddressDetails { get; set; }
}
[Table("ContactDetails")]
public class ContactDetails: Customer
{
public string MobileNo { get; set; }
public string EmailId { get; set; }
}
[Table("AddressDetails")]
public class AddressDetails: Customer
{
public string BillingAddress { get; set; }
public string DeliveryAddress { get; set; }
}
My question is, have I created the association and navigation properties correctly or do I need to add them in the ContactDetails and AddressDetails class as well? Also, when I run the code the entities are getting created in the database but for the Customer table there are 2 additional columns created as AddressDetails_Id(FK,int,null) and ContactDetails_Id(FK,int,null). I think they are created because of the navigation property but I do not need these columns in the database to be created. Also the values are always null in these two columns.
Any help would be appreciated. Thanks in advance.
I want to have cascade delete in 1:1 relationship, where i reference multiple entities to one. Problem is throws me an error on database update
Introducing FOREIGN KEY constraint 'FK_dbo.CategoryArticles_dbo.Articles_Article_Id' on table 'CategoryArticles' may cause cycles or multiple cascade paths. Specify ON DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY constraints.
RoutingSeo entity is for storing seo friendly url in database for later usage. My problem is clearly M:N relationship between Article and Category. Is there something how can I deal with this problem?
Here are my entities of my model
public class Article : IEntity<int>
{
public int Id { get; set; }
public string Name { get; set; }
public ICollection<Category> Categories { get; set; }
[Required]
public virtual RoutingSeo RoutingSeo { get; set; }
public int RoutingSeoId { get; set; }
}
public class Category : IEntity<int>
{
public int Id { get; set; }
public string Name { get; set; }
public ICollection<Article> Articles { get; set; }
[Required]
public virtual RoutingSeo RoutingSeo { get; set; }
public int RoutingSeoId { get; set; }
}
public class SpecificProduct : IEntity<int>
{
public int Id { get; set; }
public string Name { get; set; }
[Required]
public RoutingSeo RoutingSeo { get; set; }
public int RoutingSeoId { get; set; }
}
public class RoutingSeo : IEntity<int>
{
public int Id { get; set; }
public string SeoRoute { get; set; }
public Article Article { get; set; }
public SpecificProduct SpecificProduct { get; set; }
public Category Category { get; set; }
}
Here is my fluent api code where i specify cascade delete
modelBuilder.Entity<Article>()
.HasRequired(x => x.RoutingSeo)
.WithOptional(x=>x.Article)
.WillCascadeOnDelete();
modelBuilder.Entity<Category>()
.HasRequired(x => x.RoutingSeo)
.WithOptional(x=>x.Category)
.WillCascadeOnDelete();
modelBuilder.Entity<SpecificProduct>()
.HasRequired(x => x.RoutingSeo)
.WithOptional(x=>x.SpecificProduct)
.WillCascadeOnDelete();
You are right, it is your many-to-many relation ship between Article and Category: one Article has zero or more Categories and every Category may be used by zero or more Articles.
If you delete an Article, its Categories can't be deleted automatically, because the Category might be used by other Articles, and even if it isn't used right now, entity framework doesn't know whether you want to use it tomorrow. After all, you specified that every Category might be used by zero or more Articles.
Similarly, if you remove a Category, entity framework can't automatically remove the Articles belonging to this category.
This differs from a one-to-many relationship. For example, if you have a one-to-many relationship of a Book and its Pages, then every Book has zero or more Pages and every Page belongs to exactly one Book.
If you remove the Book, then entity framework knows that it should automatically remove all Pages of the Book, which are all Pages with a foreign key BookId. If Entity Framework would only remove the Book, then we would have a bunch of Pages with foreign key value pointing to a non-existing Book. So in one-to-many relations, entity framework can cascade on delete.
Alas, in many-to-many this is not possible.
On the bright side, you have the advantage that you can delete the last Article of a Category, and keep the Category intact. Tomorrow you can add a new Article that uses this Category.
So if you want to remove an article, you manually have to remove it from the 'Categories` it uses:
many-to-many following the standard naming conventions:
class Article
{
public int Id {get; set;}
// an Article belongs to zero or more Categories:
public virtual ICollection<Category> Categories {get; set;}
...
}
class Category
{
public int Id {get; set;}
// a Category is used by zero or more Articles:
public virtual ICollection<Article> Articles{get; set;}
...
}
Don't forget to declare your ICollections virtual!
class MyDbContext : DbContext
{
public class DbSet<Article> Articles {get; set;}
public class DbSet<Category> Categories {get; set;}
}
You don't have to mention the junction-table, entity framework will make it automatically for you, but you won't have to use it for joins if you want Articles with their Categories, or Categories with their Articles, just use the ICollections
Note: As Categories is not the expected plural of Category, you'll have to tell entity framework the proper table name. Out of scope of this question.
Delete an Article, but keep all Categories it belongs to alive:
using (var dbContext = new MyDbContext(...))
{
Article articleToRemove = ...
dbContext.Articles.Remove(articleToRemove);
dbContext.SaveChanges();
}
Entity framework will automatically perform the proper joins, and remove the articleToRemove from every Category. However, the Categories won't be removed.
In fact, internally the Categories table doesn't change at all. All records with Article.Id will be removed from the junction table.
I new to the code first Entity Framework and trying to solve a optional relationship.
I have the following models
public class Customer
{
public int Id { get; set; }
public int? CardId { get; set; }
public virtual ICollection<Card> Cards { get; set; }
.......
}
public class Card
{
public int Id { get; set; }
public string Name { get; set; }
public int CustomerId { get; set; }
public virtual Customer Customer { get; set; }
.......
}
A customer may not have any cards so the relationship needs to be optional, a card must have a customer.
I have tried the following but the collection does not contain the definition for a customer.
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
//modelBuilder.Entity<Customer>()
//.HasOptional(lu => lu.Cards)
//.WithRequired(pi => pi.Customer);
}
Can anyone point me in the right direction?
Updated code to reflect suggestions below, unfortunately still no luck.
What it seems like you're trying to do is just create a One-to-Many relationship.
In your Cards model you need to include:
public int CustomerId { get; set; } // Setting up a foreign key.
With this setup, the Customer class will not need:
public int? CardId { get; set; } // not necessary anymore
With a One-to-Many relationship, the ICollection<Card> Cards automatically allows 0 items to be allowed. You do not by default have to build that collection. Think of any collection. You do not have to have any items added to that collection for it to exist. You can also add many items, and take them away later and that's okay.
I have a database, and I have entity POCO's, and all I want to use EF for is to map between the two and keep track of changes for loading, saving, etc.
I have been reading a lot of the literature (such as it is) on "Code First", and I am unclear on how much of the database information I need to supply when there is not going to be a database generated.
For example, does EF need to know which properties are keys, the maximum length of string properties, the relationships between the tables, etc.? Or if it does need to know, can it get that information from the database itself? In other words, do I have to provide [Key] annotations and such, or provide configuration information detailing the foreign-key relationships, if no database needs to be created?
UPDATE: To make things a little clearer, the following code is what I am talking about. I have to manually create this class derived from DbContext. I could supply a lot of DB information about the properties in OnModelCreating, or in attributes attached to the properties in the entity classes.
public class SchedulerContext : DbContext
{
public SchedulerContext(EntityConnection connection)
: base(connection)
{
}
public DbSet<Client> Clients { get; set; }
public DbSet<ConsultantDistrict> ConsultantDistricts { get; set; }
public DbSet<ConsultantInterviewSetting> ConsultantInterviewSettings { get; set; }
public DbSet<ConsultantUnavailable> ConsultantsUnavailable { get; set; }
public DbSet<CustomEmailTemplate> CustomEmailTemplates { get; set; }
public DbSet<DateEvent> DateEvents { get; set; }
public DbSet<Event> Events { get; set; }
public DbSet<EventItem> EventItems { get; set; }
public DbSet<EventItemUserViewed> EventItemsUserViewed { get; set; }
public DbSet<FlaggedDate> FlaggedDates { get; set; }
public DbSet<Interview> Interviews { get; set; }
public DbSet<Interviewee> Interviewees { get; set; }
public DbSet<IntervieweeNote> IntervieweeNotes { get; set; }
public DbSet<InterviewEvent> InterviewEvents { get; set; }
public DbSet<NotificationSent> NotificationsSent { get; set; }
public DbSet<SchedulerRole> SchedulerRoles { get; set; }
public DbSet<SiteEvent> SiteEvents { get; set; }
public DbSet<UnavailableHour> UnavailableHours { get; set; }
public DbSet<UserLogin> UserLogins { get; set; }
public DbSet<UserSites> UserSites { get; set; }
public DbSet<Visit> Visits { get; set; }
protected override void OnModelCreating(System.Data.Entity.ModelConfiguration.ModelBuilder modelBuilder)
{
base.OnModelCreating(modelBuilder);
modelBuilder.Entity<ConsultantUnavailable>().MapSingleType().ToTable("ConsultantsUnavailable");
modelBuilder.Entity<EventItemUserViewed>().MapSingleType().ToTable("EventItemsUserViewed");
}
}
Yes, the EF does need information on string field lengths, foreign keys, etc., in the model. For example, if a DB FK has a cascade, the EF needs to know that so that it doesn't force you to manually delete detail records; if the EF is aware of the cascade it will let the DB handle that. Similarly, if the EF is aware that a key is store-generated (e.g., auto-incremented), it won't complain when you don't set it on a new record, because it will presume that the DB will do that.
However, the code-only approach takes a "convention over configuration" approach. You don't have to specify values which the EF can guess. You can read about those here.
If you are doing Code Only, the EF doesn't look at the DB at all when creating the model.
There is no way to tell the EF to look at code and the DB to create the model. You have to choose one or the other.