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
|
I have taken over a project that uses Lightspeed ORM, it was originally created with V3, but has recently been upgraded to use V5. In this project, are two related tables TransHeader and TransRow (Parent and Child relationship). Each of these tables is mapped to a single ORM entity class. The problem is the data in these tables actually represents different forms of data, with different fields being used in each form. For example the data in these related tables represent, a General Ledger financial transaction, also an A/R Invoice, an A/R Credit Note, an A/R Payment, and A/P Invoice etc. It is a classical example of using inheritance to give strict classes for each "document" type. Unfortunately that was never done, and now there is a huge application built around this single pair of classes. My question is, is there a simple way using Lightspeed and the ORM Designer in VS2010 that I can use to split these single classes into inherited classes, one for each document type? Or is my only option to do this manually? Any and all advice is gratefully received. |
|
|
|
|
Are you able to differentiate what type of data is being stored on a per row basis via a column on each of those tables? If so you could use this as a discriminator and start building up an STI model against each where you can pull out any specific data to the sub-types into the derived entities and leave common properties on the basis. You will need a discriminator to be able to use inheritance in LightSpeed, so if not then you will need to look at either refactoring the database to make this an option or look at another approach. Is this possible given the current state of things?
|
|
|
|
|
Hi Jeremy, Many thanks for the reply. We do actually have a discriminator field. In the past, on another project where we created the model in VS first, then used the model to create the data tables in SQL this worked well. Here I am a little confused, how we would go about splitting it in the model when we already have the tables. Is it a case of just creating the entities, setting the Inheritance join, then deleting the fields form the base class, and manually adding them to the child class? Also, will it be a problem if I have fields which are common to multiple child classes? i.e. We have a InvoiceNo field, this is used on two of the child classes, but not the others. Thanks again for your help. |
|
|
|
|
Yes, what you have described are the steps to take :) I would start by defining your derived types, mapping them via an inheritance relationship back to the base and then start sorting out which fields need to be on which derived types. We have a refactoring option on the designer for promoting entities from the base up to a derived class you can use. Its also fine to have the same field defined on a subset of the derived classes but not others. Ultimately there will be a single field defined on the underlying database table and LightSpeed will determine when that field needs to be loaded. Also one thing to keep note of is that all fields which are on the derived classes only (rather than being on the base) need to be nullable in the database since they will be stored as nulls for derived types which dont have those fields defined.
|
|
|
|
|
Thanks for your advise, I have had some success in spiting my classes. But I am having serious problem with associations. If have documented the problem in http://www.mindscapehq.com/forums/thread/677761 as this thread seems to be very close to what I am experiencing. Many thanks Mark |
|
|
|
