This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi Guys,
I was adding a couple of new tables to our database/model. Currently there are two: ActionStatus and SpecificActionStatus (not the actual names, but close enough ;-)). Currently I could set this up easily with Single Table Inheritance, but for a number of reasons I chose to do this with Concrete Table Inheritance (for one, I expect a larger number of SpecificActionStatus like tables, each with their own specific fields).
I tried to do this by having the (concrete) table ActionStatus as the base table and inherit SpecificActionStatus from it using CTI and in the model there is no problem. Also, when I add a new record to SpecificActionStatus, this works ok, but when I attempt to add a record to ActionStatus (the concrete base table), I get a message that SpecificActionStatus is not discriminated.
When I add an entity ActionStatusBase and derive both ActionStatus and SpecificActionStatus from this base entity through CTI, it works correctly.
Is there a way to have my original setup to work (as it saves an entity ;-))? Also, my current build of LS (v2.2) does not have anything to set 'abstract' on the base class. Is this going to be a problem? Should I add this through a partial class (not sure if this would work... haven't tried it)?
Thanks,
Robert
|
|
|
LightSpeed really supports only leaf classes in CTI scenarios (it also has some other restrictions such as associations must always be to leaf classes rather than base classes, due to our not supporting polymorphism with CTI). So your original setup will not work I'm afraid -- you will need to add that ActionStatusBase class. Yes, you can mark the base class as abstract through the partial class. Alternatively, current nightly builds provide an Inheritance setting which allows you to mark an entity as abstract in the designer: the benefit of this is that it enables database synchronisation of CTI derived classes (we do not allow database sync when there is a concrete base class). Please note that if you are upgrading from 2.2 RTM to a nightly build then you MUST manually uninstall the RTM before installing the nightly (unfortunately it *doesn't* warn you about this, but if you don't do it then you will get strange errors in the designer). |
|
|
Hi Ivan,
Ok, fair enough. I'll stick with the ActionStatusBase implementation then.
For now I don't think I'll be able to upgrade to a nightly build, but since I can add the abstract bit through the partial class, I'll do that, but will I get into any weird issues when NOT adding the abstract keyword, other than that users (just me) would be able to instantiate ActionStatusBase?
Thanks for ur quick answer as always...
Robert
|
|
|
No, the LightSpeed runtime does not require CTI base classes to be abstract. It is merely a helpful way to prevent you accidentally using a base class which is not backed by a table. You should have no problems with your CTI base classes being concrete provided you never instantiate them. (As mentioned the designer takes a slightly stricter view of the matter, but that's because it's concerned about database schema synchronisation; it doesn't matter for loading and saving entities.) |
|
|
Cool... Thanks ;-)
|
|