We Keep Coding

Mapping viewModel object to ICollection entity

I have a basic table with a few FK references. So when I retrieve an entity for an update operation; that entity contains ICollections of related entites. My main viewModel contains Lists which correspond to these ICollections. However, since some other models represent 1-1 mapping, I have object instead of List. But inside the Entity they continue to be represented as ICollections.
This is giving me some problems when trying to map between viewModel and Entity. I am using Automapper for the mapping. I have
mapper.Map(viewModel, entity);
Currently I am leaving out the problematic models from this mapping and adding them separately. Is there a way to handle everything in one mapping? Is there a way to deal with the ICollections which ideally should be a single object?
EDIT
public class MainViewModel
{
public EntityVM1 vm1 { get; set; }
public List<EntityVM2> vm2 { get; set; }
public List<EntityVM3> vm3 { get; set; }
}
public class MainEntity
{
... some scalar props...
public virtual ICollection<Entity1> e1 { get; set; }
public virtual ICollection<Entity2> e2 { get; set; }
public virtual ICollection<Entity3> e3 { get; set; }
}
Entity1 and EntityVM1 are causing the problem.
Thanks

You can always override the default mapping system in the mapping config of AutoMapper, you should have a peek at the runtime polymorphism in the mapping inheritance section of the documentation.
If what you want on the entity is a straight object, why not take Automapper out of the equation and just force EF to map it using a one to one system... i.e
modelBuilder.Entity<MainEntity>()
.HasOne(p => p.Entity1)
.WithOne(i => i.MainEntity)
.HasForeignKey<Entity1>(b => b.MainEntityForignKey);
HAve a peek at the EF docs, under section one-to-one for more info

Duplicate ForeignKey when using inheritance

I have created these classes in order to generate the database model via EntityFramework 6 code-first approach:
public class Vehicle
{
public long Id { get; set; }
public long ResponsiblePersonId { get; set; }
}
public class Car: Vehicle {
public int HorsePower { get; set; }
}
public class Bike: Vehicle {
public int FrameSize { get; set; }
}
public class Organisation
{
public Organisation()
{
Cars = new List<Car>();
Bikes = new List<Bikes>();
}
public long Id { get; set; }
public List<Car> Cars { get; set; }
public List<Bike> Bikes { get; set; }
}
So far this seemed right for me.
But unfortunately, the resulting table looks like this:
Id | ResponsiblePersonId | HorsePower | FrameSize | Discriminator | Organisation_Id | Organisation_Id1
Why is the Organisation ForeignKey being generated twice? I expected this table to only have one Organisation_Id column.
Thanks

There are several ways for EF to implement the physical tables for your inheritance hierarchy. The default one, the one you are using, is called Table Per Hierarchy (TPH). It uses only one table for all the derived entities, with one Discriminator column to specify the type of entity which is contained in the record. EF also adds to the table a column for each property that is included in any of the derived entities.
So as the relationship between the derived entities and Organisation is defined at child level (the lists of Car and Bike properties in Organisation entity) EF decides to create a separate column for each child entity type Organisation_Id, and you don't want that.
How to change this? There are several ways:
Don't use TPH. Use instead TPC (Table Per Concrete class). That is, EF creates a separate table for each one of your child entities. How to do this: remove the DbSet<Vehicle> property from your DbContext. If this doesn't make it, set an explicit configuration for the physical table name for each entity derived from Vehicle like this:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
...
modelBuilder.Entity<Car>().ToTable("Cars");
modelBuilder.Entity<Bike>().ToTable("Bikes");
}
If you need to continue using TPH, I don't know of any way to implementing this that will generate only one OrganisationId column in the database and only one Foreign Key between Vehicle and Organisation. Common sense would say that you might define the Organisation foreign key at the Vehicle base entity level. But then you get errors when generating the migration:
Organisation: FromRole: NavigationProperty 'Organisation' is not
valid. Type 'Car' of FromRole 'Organisation_Cars_Target' in
AssociationType 'Organisation_Cars' must exactly match with the type
'Vehicle' on which this NavigationProperty is declared on.
It seems that when the relationship is defined at base level then EF expects the lists in Organisation to be defined of type Vehicle and not Car or Bike. And this does not fit with your model.
And if you try to define OrganisationId or Organisation properties in your derived classes then you get a different error when generating the migration, because you are not allowed to use the same name for the properties in the different child entities. You can use different names, but then you get two columns again. There is no way to get one column this way either.
So if you stick with TPH, as far as I know, you have to put up with having two columns for your OrganisationId. At least you can name them in a more verbose way with some fluent configurations:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
...
modelBuilder.Entity<Organisation>()
.HasMany(o => o.Bikes)
.WithRequired()
.Map(x => x.MapKey("OrganisationIdBike"));
modelBuilder.Entity<Organisation>()
.HasMany(o => o.Cars)
.WithRequired()
.Map(x => x.MapKey("OrganisationIdCar"));
}
I would recommend you to change to TPC, as with your model the fluent mappings are a bit less complex to write.
For a better understanding of TPH, TPC and TPT (Table Per Type, yet another implementation of inheritance hierarchies) read this post.

Entity Framework invalid object name "dbo.EA_EmployeePerformance"

It is weird since I use the simple membership initialization my EF model cannot create a new table. My code was able to create the new table needed if there is a transaction required for the model.
This is my model :
public class EmployeeDBContext : DbContext
{
public EmployeeDBContext()
: base("DefaultConnection")
{
Database.SetInitializer<EmployeeDBContext>(new CreateDatabaseIfNotExists<EmployeeDBContext>());
}
public DbSet<EA_Employee> Employees { get; set; }
public DbSet<EA_EmployeePerformance> EmployeePerformances { get; set; }
public DbSet<EA_EmployeeRank> EmployeeRanks { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Conventions.Remove<OneToManyCascadeDeleteConvention>();
modelBuilder.Conventions.Remove<PluralizingTableNameConvention>();
}
}
[Table("EA_EmployeePerformance")]
public class EA_EmployeePerformance
{
[Key]
[DatabaseGeneratedAttribute(DatabaseGeneratedOption.Identity)]
[Display(Name = "Employee Performance Id")]
public int EmployeePerformanceId { get; set; }
[Index("Performance", IsUnique = true)]
[MaxLength(20)]
[Required]
public string Performance { get; set; }
public EA_EmployeePerformance()
{
Performance = "";
}
}
Whenever I SaveChanges(), the DB throws me
"Invalid object name dbo.EmployeePerformance".
I check the database and the database only contains tables required from simple membership.
How can I auto create the tables when a transaction is occurred for that model?
--------- EDITED ---------
Now I know what is my problem. The problem is because I use multiple dbContext in one database. It is gonna be tricky to do the migration because migration only works on one dbContext isn't it?
So in my case the problem is because the original AccountDBContext from the simple membership is taking over my database, that is why my other dbContext such as the EmployeeDBContext cannot create the new table (please correct me if i'm wrong).
Is there a way for me to keep the multiple dbContexts in a single database?

First you have to change your Db Initializer to DropCreateDatabaseIfModelChanges otherwise, you will still have the old database and you will never get the model changes without deleting the database manually.
database. It is gonna be tricky to do the migration because migration only works on one dbContext isn't it?
For migration I recommend you to create one DbContext for migration that called for Example MigrationDbContext which contains the the all DbSets and the POCO objects, also when the POCO objects belong to other assembly then just reference them.

Try using Migrations, this will help you manage your changes in your code and update the database scheme accordingly.
Here is a guide for how to use it Migrations.

An Entity with identical table data

Before I elaborate the problem, I'm well aware the database isn't designed conventionally. Sadly, I can't change this particular database due to how it is integrated, so I've got a potential solution but that won't be implemented for several months. In the mean time I need to work around the following:
The problem is I need to build an Entity, this would represent our Accounts. But the problem, our database implements the following structure:
Invoiced Table
Non-Invoiced Table
My Entity, represents the exact same data on those tables, same column names, duplicate under all conditions, except one is invoiced while the other represents non-invoiced customers. But since it isn't one table, with a Flag to indicate invoiced versus non-invoiced, how can my Entity link to both of those tables?
Since both tables represent separate names, I can't use the [Table("...")] or the auto mapping capabilities. I hate asking such a question, but I can't find any documentation on how to handle such an issue.

You could use table-per-concrete class inheritance then define the table names on the derived types:
public abstract class Account
{
// common entity code here
...
}
public class InvoicedAccount : Account {}
public class NonInvoicedAccount: Account {}
public YourContext : DbContext
{
public DbSet<InvoicedAccount> InvoicedAccounts { get; set; }
public DbSet<NonInvoicedAccount> NonInvoicedAccounts { get; set; }
protected override void OnModelCreating( DbModelBuilder modelBuilder )
{
modelBuilder.Entity<InvoicedAccounts>().Map( m =>
{
m.MapInheritedProperties();
m.ToTable( "InvoicedAccountTable" );
} );
modelBuilder.Entity<NonInvoicedAccounts>().Map( m =>
{
m.MapInheritedProperties();
m.ToTable( "NonInvoicedAccountTable" );
} );
}
}

Unhandled Exception after Upgrading to Entity Framework 4.3.1

Error:
Unhandled Exception: System.Data.SqlClient.SqlException: The operation failed because an index or statistics with name 'IX_ID' already exists on table 'PrivateMakeUpLessons'.
Model (Simplified, building in a separate test project for debugging):
public abstract class Lesson
{
public Guid ID { get; set; }
public string Room { get; set; }
public TimeSpan Time { get; set; }
public int Duration { get; set; }
}
public abstract class RecurringLesson : Lesson
{
public int DayOfWeek { get; set; }
public DateTime StartDate { get; set; }
public DateTime EndDate { get; set; }
public string Frequency { get; set; }
}
public class PrivateLesson : RecurringLesson
{
public string Student { get; set; }
public string Teacher { get; set; }
public virtual ICollection<Cancellation> Cancellations { get; set; }
}
public class Cancellation
{
public Guid ID { get; set; }
public DateTime Date { get; set; }
public virtual PrivateLesson Lesson { get; set; }
public virtual MakeUpLesson MakeUpLesson { get; set; }
}
public class MakeUpLesson : Lesson
{
public DateTime Date { get; set; }
public string Teacher { get; set; }
public virtual Cancellation Cancellation { get; set; }
}
Configuration:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Lesson>().ToTable("Lessons");
modelBuilder.Entity<RecurringLesson>().ToTable("RecurringLessons");
modelBuilder.Entity<PrivateLesson>().ToTable("PrivateLessons");
modelBuilder.Entity<MakeUpLesson>().ToTable("PrivateMakeUpLessons");
modelBuilder.Entity<Cancellation>()
.HasOptional(x => x.MakeUpLesson)
.WithRequired(x => x.Cancellation);
base.OnModelCreating(modelBuilder);
}
Notes:
This worked fine in EF 4.2. Is there something wrong with my model? The actual model is much more complicated which is why I have all the classes abstracted out. Also, I am working against an existing database so I need to use Table-Per-Type inheritance.
If I change the relationship of Cancellation to PrivateMakeUpLesson from 1 to 0..1 to 0..1 to 0..1 it works. This is undesirable because you can't have a PrivateMakeUpLesson without a Cancellation.
Also, if I make PrivateMakeUpLesson NOT inherit from Lesson then it also works, but it IS a lesson and needs to remain so for existing business logic.
I'd appreciate any guidance. Thank you!
Edit:
Starting a bounty. I can't find any documentation on what changed between EF 4.2 and EF 4.3 with regard to the index generation for code first. It's clear that EF 4.3 is creating more indexes and that the naming scheme has changed but I want to know if there's a bug in EF or if there is something fundamentally wrong with my model or fluent API configuration.

As of EF 4.3, indexes are added for freign key columns during database creation. There is a bug that can cause an index to be created more than once. This will be fixed in a future EF release.
Until then, you can work around the issue by creating your database using Migrations instead of database initializers (or the Database.Create() method).
After generating the initial migration, you will need to delete the redundant call to Index().
CreateTable(
"dbo.PrivateMakeUpLessons",
c => new
{
ID = c.Guid(nullable: false),
...
})
.PrimaryKey(t => t.ID)
.ForeignKey("dbo.Lessons", t => t.ID)
.ForeignKey("dbo.Cancellations", t => t.ID)
.Index(t => t.ID)
.Index(t => t.ID); // <-- Remove this
To continue creating your database at run-time, you can use the MigrateDatabaseToLatestVersion initializer.

In my opinion this is clearly a bug.
The problem starts with the observation that EF creates an index IX_ID at all. If you strip down the model to the following...
public abstract class Lesson
{
public Guid ID { get; set; }
}
public class RecurringLesson : Lesson
{
}
public class MyContext : DbContext
{
public DbSet<Lesson> Lessons { get; set; }
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<RecurringLesson>().ToTable("RecurringLessons");
}
}
... and let EF create the database schema you get two tables Lessons and RecurringLessons as expected for a TPT inheritance mapping. But I am wondering why it creates two indices for the table RecurringLessons:
Index PK_RecurringLessons (clustered, unique) with Index column ID
Index IX_ID (not clustered, not unique) with Index column ID again
I don't know if there is any benefit for the database to have a second index on the same column. But for my understanding it doesn't make sense 1) to create an index on the same column that is already covered in the PK clustered index, and 2) to create a not unique index on a column which is the primary key and therefore necessarily unique.
Moreover due to the one-to-one relationship EF tries to create an index on the table of the dependent of this association which is PrivateMakeUpLessons. (It's the dependent (and not the principal) because Cancellation is required in entity MakeUpLesson.)
ID is the foreign key in this association (and primary key at the same time because one-to-one relationships are always shared primary key associations in Entity Framework). EF apparently always creates a index on the foreign key of a relationship. But for one-to-many relationships this is not a problem because the FK column is different from the PK column. Not so for one-to-one relatonships: The FK and PK are the same (that is ID), hence EF tries to create an index IX_ID for this one-to-one relationship which already exists due to the TPT inheritance mapping (which leads to a one-to-one relationship as well from database perspective).
The same consideration as above applies here: The table PrivateMakeUpLessons has a clustered PK index on column ID. Why is a second index IX_ID on the same column required at all?
In addition EF doesn't seem to check that it already wants to create an Index with name IX_ID for the TPT inheritance, leading finally to the exception in the database when the DDL is sent to create the database schema.
EF 4.2 (and before) didn't create any indices (except PK indices) at all, this was introduced in EF 4.3, especially indices for FK columns.
I didn't find a workaround. In the worst case you have to create the database schema manually and avoid that EF tries to create it (= disable database initialization). In the best case there is a way to disable automatic FK index creation, but I don't know if it's possible.
You can submit a bug report here: http://connect.microsoft.com/VisualStudio
Or maybe someone from EF development team will see your question here and provide a solution.

I got a very similar error to this one in my code a while back. Try putting the cancellation list inside the Lesson class. That's what solved my problem.

Below I describe 2 scenarios what is probably going wrong. Please read in depth by clicking the links I provided to know more about my explanation.
First
Lesson and RecurringLesson are abstract classes (so you want to have it as the base classes).
You are creating a table of the Lesson and the RecurringLesson entities which will result in a Table per hierarchy structure.
brief description
Creating a class of the base table will result in one big table which contains the columns of all inherited tables. So all properties of PrivateLesson, MakeUpLesson and all others inherited entities will be stored in the Lessons table. EF will add also a Discriminator column. The value of this column defaults to the persistent class name (like "PrivateLesson" or "MakeUpLesson") only the column matching to that particular entity (matching the Discriminator value) will be used in that particular row.
BUT
You are also mapping the inherited classes like PrivateLesson and MakeUpLesson. This will force EF to use the Table per Type structure which results in one table per class. This can cause conflicts you are facing right now.
Second
Your example shows you have an one-to-one relationship (Cancellation -> MakeUpLesson) and a one-to-many relationship (Cancellation -> PrivateLesson) because PrivateLesson and MakeUpLessonare both (indirect) inherited from Lesson in combination with the first described scenario can cause problems because it will result in 2 foreign key relationships in the database per entity. (one using Table per hierarchy structure and one using the Table per Type structure).
Also this post can help you defining a correct one-to-one definition.
Please verify by performing the following steps:
I assume you have your own test environment so you can create new test databases
1.
Delete the relationships to the Cancellation by commenting out all properties to this class:
public class PrivateLesson : RecurringLesson
{
public string Student { get; set; }
public string Teacher { get; set; }
//public virtual ICollection<Cancellation> Cancellations { get; set; }
}
public class Cancellation
{
public Guid ID { get; set; }
public DateTime Date { get; set; }
//public virtual PrivateLesson Lesson { get; set; }
//public virtual MakeUpLesson MakeUpLesson { get; set; }
}
public class MakeUpLesson : Lesson
{
public DateTime Date { get; set; }
public string Teacher { get; set; }
//public virtual Cancellation Cancellation { get; set; }
}
And remove the configuration to it:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Entity<Lesson>().ToTable("Lessons");
modelBuilder.Entity<RecurringLesson>().ToTable("RecurringLessons");
modelBuilder.Entity<PrivateLesson>().ToTable("PrivateLessons");
modelBuilder.Entity<MakeUpLesson>().ToTable("PrivateMakeUpLessons");
//modelBuilder.Entity<Cancellation>()
// .HasOptional(x => x.MakeUpLesson)
// .WithRequired(x => x.Cancellation);
base.OnModelCreating(modelBuilder);
}
2.
Create a new empty database
3.
Let EF generate the table structure for you in this empty database.
4.
Verify the first scenario. If that's true this need to be fixed first by using the Table per hierarchy structure OR the Table per Type structure. Probably you want to use the Table per hierarchy structure because (if I understand your question well) there is already an production environment.

When my project was updated from EF 6.0.2 to EF 6.1.1, I had such a problem, then back to 6.0.2, after the return of an older version, the error disappeared