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.
Thank you for your suggestion on improving LightSwitch. However, Visual Studio 2015 is the last release of Visual Studio that includes the LightSwitch tooling and we recommend users not begin new application development with LightSwitch. That said, we will continue to support users with existing LightSwitch applications, including critical bug fixes and security issues as per the Microsoft Support Lifecycle. Please see the blog post for more information: https://blogs.msdn.microsoft.com/lightswitch/2016/10/14/lightswitch-update/
– The Visual Studio Team
Jason R. Craig commented
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 Goblin commented
Can't we work around this by building a separate OData project with inheritance? I still suppose Lightswitch won't understand much about it...
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
"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 Kung commented
Thank you for the suggestion! Would you mind sharing your scenarios? Could it be solved with simply using relationship between tables?
- LightSwitch Team