locked
TPC: prevent creation of abstract class tables. RRS feed

  • Question

  • User1088965359 posted

    I'm trying to implement a code-first scenario where Abstract Base classes are used ONLY for defining the table-models 

    the point is to define similar properties ONCE and then let the inheritance work its magic.

    what i'm experiencing and have found out the hard way, is that i have to choose between TPT, TPH or TPC inheritance modelling where none of them give me what i want.

    TPC seems to be the most relevant - but i CANNOT fathom why EF6 creates Tables for the Abstract baseclasses !??

    I dont want to create collections of type: <abstract baseclass> like seen in this example: https://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines

    i don't get why you would ever do that .. meaning - why you would add inherited classes into a dbcontext of type <abstract baseclass> .. ???

    Is it possible to have EF, ONLY use the concrete instantiable classes and somewhat ignore the abstract classes ?

    eg: 

    abstract class BaseModel
    {
       public int ID {get;set;}
    }
    
    class A : BaseModel
    {
       public string A {get;set;}
    }
    
    class B : BaseModel
    {
       public string B {get;set;}
    }
    
    // Should result in 
    
    Table A [ ID int, A varchar() ]
    Table B [ ID int, B varchar() ]

    Monday, May 14, 2018 10:56 AM

Answers

  • User1724605321 posted

    Hi Montago ,

    Reference : https://social.msdn.microsoft.com/Forums/en-US/30086074-6773-4b83-bed5-88a401fb2a4e/ef-41-code-first-and-tpc-inheritance-mapping?forum=adodotnetentityframework 

    What you are describing seems to match a an issue we found very late in EF 4.1 RTW cycle and we decided to postpone because our evaluation indicated that it had very low impact: while this unnecessary table is created for an abstract base type, the table does not participate in any mapping, therefore it shouldn't appear in any query produced by EF.

    For case in which you are using Code First to generate the database, the table will be added to the database schema but never used. For cases in which you are using the Code First API to map to an existing database it shouldn't have an impact either, since no queries generated by EF will every fail because the table is not there.

    You can just remove that table , or try the solution suggested in this thread .

    Best Regards

    Nan Yu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 15, 2018 6:29 AM

All replies

  • User753101303 posted

    Hi,

    It shows the class diagram and seems to tell it should give a db schema with just the BankAccounts and CreditCards table. You followed ALL the steps and this is not the behavior you see?

    Edit: not directly related but I've never really been convinced that sharing an ID property is a good use case for inheritance. This is just a technical need and I would use inheritance rather when it makes sense from a business perspective.

    Monday, May 14, 2018 11:09 AM
  • User1088965359 posted

    yes, i followed ALL steps... including the modelBuilder configuration. 

    yet - when running add-migration / update - the abstract class/table will be created in the database :( 

    The example i gave is only for illustration - my datamodel is way more extensive. 

    I'm using it to combine logic for BasketHead, BasketLines, OrderHead and OrderLines which have very similar characteristics : Head + Lines  

    Monday, May 14, 2018 11:27 AM
  • User1724605321 posted

    Hi Montago ,

    Reference : https://social.msdn.microsoft.com/Forums/en-US/30086074-6773-4b83-bed5-88a401fb2a4e/ef-41-code-first-and-tpc-inheritance-mapping?forum=adodotnetentityframework 

    What you are describing seems to match a an issue we found very late in EF 4.1 RTW cycle and we decided to postpone because our evaluation indicated that it had very low impact: while this unnecessary table is created for an abstract base type, the table does not participate in any mapping, therefore it shouldn't appear in any query produced by EF.

    For case in which you are using Code First to generate the database, the table will be added to the database schema but never used. For cases in which you are using the Code First API to map to an existing database it shouldn't have an impact either, since no queries generated by EF will every fail because the table is not there.

    You can just remove that table , or try the solution suggested in this thread .

    Best Regards

    Nan Yu

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Tuesday, May 15, 2018 6:29 AM
  • User1088965359 posted

    ahh, just a bug in EF then :) 

    thanks

    Tuesday, May 15, 2018 10:46 AM