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 again, anyone else than me having a problem updating the model to database when an entitys inheritance is marked as abstract? Nothing happens when I use the context menu and try to update (no message, nothing). It works again when removing the attribute. |
|
|
|
|
When an entity is marked as abstract, LightSpeed assumes that it is not backed by a database table (because you can never materialise entities of that type, only of derived types), and therefore that there is no update work to do. However, that fact that it just does nothing rather than displaying a message is a bug -- thanks for alerting us to this and we'll see if we can get it fixed for you. |
|
|
|
|
Thanks for your answer, but I don't understand where the data should be stored then? If I have an abstract entity "Person", it has a name and that must be saved too. :) (I'm using SingleTableInheritance.) |
|
|
|
|
Hmm, we don't normally recommend making STI base classes abstract, because that can cause problems if the discriminator doesn't match any derived classes. However, you can do this by not setting Inheritance=Abstract in the designer, but then creating a partial class and applying the abstract modifier there: abstract partial class Person { /* empty */ } The designer doesn't know about the partial class, so it thinks the Person entity is concrete and creates a table for it. But the modifier still gets applied to the entity class so you get the desired abstract class behaviour. We should probably update the designer so that non-ConcreteTableInheritance base classes *do* get included in database sync -- thanks for drawing this to our attention. |
|
|
|
|
Further to this, syncing to the database does not seem to create the Discriminator column. Ex: I in the designer I create an abstract base entity called RecordBase, from which Sale, Layby, and Return concrete entities inherit. On each inheritance link I set Discriminator Name to "SaleType", Inheritance Type to "SingleTableInheritance", and set Discriminator Values of "Sale", "Layby" and "Return" appropriately. Syncing this to the database (with Inheritance temporarily set to 'Default' to work around the issue discussed above) doesn't result in a SaleType discriminator column being created. Should we be creating this column manually in the db, or have I got my setup wrong? |
|
|
|
|
Designer sync requires that the discriminator be declared as a property (which is normally the case anyway). So add a SaleType property in the base class and you should be good to go. If you don't want the SaleType property to be surfaced in your API, set its Generation option to FieldOnly: this will create the private field, but not the wrapper property, so users of your model won't see it. |
|
|
|
