I suggest you ...

Table Inheritance

Make Table inheritance. So developer could make some BaseTable (entity) and a number DerivedTables (entities) witch will inherit properties from base table. And also it would be great to mix properties from base and/or derived tables in queries.

89 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    AnonymousAnonymous shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

    5 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Jason R. CraigJason R. Craig commented  ·   ·  Flag as inappropriate

        I think the real problem lies with domain services not supporting inheritance, it will only pick up the entities in the EDM which are not derived from other entities and the checkboxes are greyed out for the derived entities.

      • Tec GoblinTec Goblin commented  ·   ·  Flag as inappropriate

        Can't we work around this by building a separate OData project with inheritance? I still suppose Lightswitch won't understand much about it...

      • herbertherbert commented  ·   ·  Flag as inappropriate

        Pls support Entity Framework Code First Metadata from Lightswitch:
        1) Enumeration Tables (finished in EF Code First 4.1) => Choicelist
        2) Entity Framwork Inheritance schemas: TPH/TPT/TPC
        e.g. base table + inheritance table should become Lightswitch table

      • SleeperSmithSleeperSmith commented  ·   ·  Flag as inappropriate

        "Thank you for the suggestion! Would you mind sharing your scenarios? Could it be solved with simply using relationship between tables?"

        Yes and no. Yes we can make do with relationship. No it's not ideal from data integrity and data modelling point of view. In my scenario, we have a base contract and many other "types" of derived contracts. My application was built with MVC/Entity Framework using Table per Hierarchy configuration.

        (Please bear in mind I'm no LS expert) To achieve similar experience in LightSwitch, I will need to custom code to show/hide the relevant fields.

        Now, I guess Table per Type will be more ideal in this situation, but it's still a lot of work to map in the constraints (whether it be Database constraint or code constraint.) That and many other irrational ways of dealing with the relationship. (such as choosing and displaying the "type" a particular row is.)

        It really is a value worthy feature to add imo. But then, Entity Framework's table inheritance feature was added only a while ago, so I wouldn't hold my breath when LightSwitch has it added in. (LS uses entity framework right?)

      • Andy KungAndy Kung commented  ·   ·  Flag as inappropriate

        Thank you for the suggestion! Would you mind sharing your scenarios? Could it be solved with simply using relationship between tables?

        - LightSwitch Team

      Feedback and Knowledge Base