I would like to be able to map the same table to multiple entities. This is useful for query purposes (restricted views of data), as well as for inserting different sets of data into a table. This is useful for TPH scenarios where you could map a separate class that contains the descriminator column as an assignable property. In this way you can insert a "generic" record, and query a specific instance in the TPH heirarchy.
Comments: Thanks for the feature suggestion. Let me explain a bit of background in EF mapping that would be impacted by such a change. EF view generation ensures that data can be round-tripped from the database without any data-loss. That is, when you query some data from the database and then write that data back using SaveChanges the data written back will be the same as was queried. For this to work the mapping needs to be non-overlapping. In other words, a column must be mapped to one-and-only-one property, condition, etc. As soon as multiple mappings are introduced the ability for view generation to ensure round-tripping is lost. Now it is certainly possible to use multiple mappings without causing data loss so long as you know what you're doing and understand the consequences of that. But it's hard to separate that from people just shooting themselves in the foot because they are creating multiple/overlapping mappings without realizing the consequences. One way to achieve the same thing as multiple mappings is to use different DbContext types for the different mappings with different Code First models backing those contexts. You can of course the same data corruption using this mechanism but it is at least very explicit about what is happening. Unless we come up with significant new ideas we’re not going to work on this change and it’s unlikely we would accept a pull request for this unless it can be done in a way that maintains the round-tripping validation done by view generation, which would be a hard thing to do. Thanks, Arthur
Comments: Thanks for the feature suggestion. Let me explain a bit of background in EF mapping that would be impacted by such a change. EF view generation ensures that data can be round-tripped from the database without any data-loss. That is, when you query some data from the database and then write that data back using SaveChanges the data written back will be the same as was queried. For this to work the mapping needs to be non-overlapping. In other words, a column must be mapped to one-and-only-one property, condition, etc. As soon as multiple mappings are introduced the ability for view generation to ensure round-tripping is lost. Now it is certainly possible to use multiple mappings without causing data loss so long as you know what you're doing and understand the consequences of that. But it's hard to separate that from people just shooting themselves in the foot because they are creating multiple/overlapping mappings without realizing the consequences. One way to achieve the same thing as multiple mappings is to use different DbContext types for the different mappings with different Code First models backing those contexts. You can of course the same data corruption using this mechanism but it is at least very explicit about what is happening. Unless we come up with significant new ideas we’re not going to work on this change and it’s unlikely we would accept a pull request for this unless it can be done in a way that maintains the round-tripping validation done by view generation, which would be a hard thing to do. Thanks, Arthur