Otis, Using inheritance (one table per entity), I have a base object and it has three sub objects. This is of course represented in the database correctly and everything works just fine. The base class is abstract.

Now, each of my child object has a field called 'Description'. I would like to be able to have an object of type BaseClass that I can call Description on and get that child value.

Normally, I would just create a virtual property of Description in the base abstract class and then each subclass would override that. However, in this case llblgen generates properties called 'Description' for each sub class, so that does not work.

In case I am not clear, some code:

MyBaseClassEntity someEntity = MyBaseClassEntity.FetchPolymorphic(.....);

...at this point someEntity contains an entity that DOES have a Description field, but of course I cannot do:

someEntity.Description;

I can do (because the Description field is not in the base class, but each child class has this):

someEntity.Fields['Description'];

As usual, your first answer would not be how to solve this, but question my design - so let me give that to you ahead of time.

Each child class has different fields that are unique to the child class (as would be normal in a hierarchy). I then create a calculated field (in sqlserver) called 'description' that concats some of these these fields together to create this description. So, moving this 'description' to the parent class is not an option.

I thought of creating a property called Description in the abstract class and let it operate on Fields['Description'], but each subclass would emit a duplicate property....

Any ideas on how to make LLBLGen handle this situation for me a bit cleaner?

I thought of creating a property called Description in the abstract class and let it operate on Fields['Description'], but each subclass would emit a duplicate property....

I would do that. You could name it different, something like "DescriptionBase"

I don't like it. Would rather have something a little cleaner...if there is something possible. Maybe Otis will weigh in.

if each sub type share the same field, you have to define the field on the super type, i.e. the supertype entity. It then is defined in that entity, and as every subtype has the field, it doesn't matter.

there's no code solution for this, you have to do it the way I described it above, as that's the only way it makes sense in an abstract entity model way. Code follows entity model, not the other way around.

As I said above, it is impossible to define it in the super type as the field is comprised of data in the subtypes. (I guess I could define it there as a real field, then us a trigger to populate, etc..don't want to do that).

Imagine your example model with cars. I would create a calculated field in SQLServer (if it stores it is not relevant - it may or may not be a 'stored' calculated field, does not matter).

For SportsCar it may be:

Description = Year+' '+EngineType+' with '+Suspension+' ' So, SportsCar.Description would be "2009 V8 with super awesome suspension"

For FamilyCar it may be:

Description = Year+' seating '+PeopleSeating+' people' So, FamilyCar.Description would be "2009 seating 12 people"

For CompactCar it may be:

Description = Year+' seating '+PeopleSeating+' people, '+ MPG+' MPG' So, FamilyCar.Description would be "2009 seating 12 people, 28 MPG"

as you can see the Description (field/calculation) cannot be the the supertype, but is guaranteed to be in the subtypes. This enables me to do a collection of cars in a report for example and display a description easily.

There may not be a good code solution for this - but as you can see above I do have other 'solutions' for it. In fact, I could define 'Description' in the abstract class that does Fields["Description"], but will get compiler warnings as I would need the 'new' modifier on the properties in the subtypes.

Thoughts?

WayneBrantley wrote:

As I said above, it is impossible to define it in the super type as the field is comprised of data in the subtypes. (I guess I could define it there as a real field, then us a trigger to populate, etc..don't want to do that).

Imagine your example model with cars. I would create a calculated field in SQLServer (if it stores it is not relevant - it may or may not be a 'stored' calculated field, does not matter).

For SportsCar it may be:

Description = Year+' '+EngineType+' with '+Suspension+' ' So, SportsCar.Description would be "2009 V8 with super awesome suspension"

For FamilyCar it may be:

Description = Year+' seating '+PeopleSeating+' people' So, FamilyCar.Description would be "2009 seating 12 people"

For CompactCar it may be:

Description = Year+' seating '+PeopleSeating+' people, '+ MPG+' MPG' So, FamilyCar.Description would be "2009 seating 12 people, 28 MPG"

as you can see the Description (field/calculation) cannot be the the supertype, but is guaranteed to be in the subtypes. This enables me to do a collection of cars in a report for example and display a description easily.

There may not be a good code solution for this - but as you can see above I do have other 'solutions' for it. In fact, I could define 'Description' in the abstract class that does Fields["Description"], but will get compiler warnings as I would need the 'new' modifier on the properties in the subtypes. Thoughts?

Is it a field in some table? As it seems it isn't, as you create the value at runtime (so it's a property added manually ? )

This thus means that you can simply define it as abstract in the partial class of the supertype, and then implement it in the derived types' partial classes. I don't see any other way. Is it a field in an entity, (thus in the abstract entity model, forget code), the only logical place it should be is in the supertype of all types which have this property, as then all inherit it from the supertype.

If you want to set a description field to a value based on the values in the subtype, why don't you create a method in the subtypes which set the Description field, based on the pre-fab patterns? You then have the Field in the supertype, and the value the field gets is computed in the subtypes.

It is a field in the subtype tables. It is in every one of them. The calculation you see is done by SQLServer so that it is available in views, procs, etc.

In the abstract entity model it is contained in EVERY subtype - but the field is calculated from subtype fields, therefore cannot be in the supertype! Like in my example above. If you wanted to have the 'description' field - you would put it in every subtype and setup SQLServer to calcluate it for you.

I guess the only way to make this work with your stuff would be to put the description field in the supertype and then write a trigger to update that description when the subtypes changed. Right now, the way it is, no crazy trigger is required and no storage of the description is actually used. I like the way it is now, just this ONE SINGLE drawback in the code that is generated.

Again, if I could get the 'new' keyword thrown on this one property, I could make this seamless.

Thanks for your input.

BTW, (and yes I am bugging you) did you notice the 1yr anniversary of the release of 2.6 just passed us....wonder where 3.0 is. Anxiously awaiting what you have in store for us.

WayneBrantley wrote:

It is a field in the subtype tables. It is in every one of them. The calculation you see is done by SQLServer so that it is available in views, procs, etc.

aha! that's vital info, the value is calculated inside the DB. Then it makes sense.

In the abstract entity model it is contained in EVERY subtype - but the field is calculated from subtype fields, therefore cannot be in the supertype! Like in my example above. If you wanted to have the 'description' field - you would put it in every subtype and setup SQLServer to calcluate it for you.

Indeed, I now understand why it has to be in the subtypes.

I guess the only way to make this work with your stuff would be to put the description field in the supertype and then write a trigger to update that description when the subtypes changed. Right now, the way it is, no crazy trigger is required and no storage of the description is actually used. I like the way it is now, just this ONE SINGLE drawback in the code that is generated.

I see. There's one thing you could do though: define an interface, IDescriptionProvider, or whatever, and in the designer, you define that as an extra interface to implement on the subtypes. (Code generation tab on the entity -> output specific settings tab)

Then in your code, you define the interface as an interface with just 1 property: Description.

Then in your entity consuming code, you use 'as' to cast to IDescriptionProvider and if the result is not null, you simply read the Description property:

string description = string.Empty; IDescriptionProvider e = someEntity as IDescriptionProvider if(e!=null) { description = e.Description; }

Again, if I could get the 'new' keyword thrown on this one property, I could make this seamless.
Thanks for your input.

It's a bit problematic I think, and 'new' isn't really working, what you want is a common interface to see all subtypes through. As the supertype doesn't have a description, it doesn't make sense to define it there, however you want to read the description of the subtype, regardless what type it is, and interfaces are meant for that.

BTW, (and yes I am bugging you) did you notice the 1yr anniversary of the release of 2.6 just passed us....wonder where 3.0 is. Anxiously awaiting what you have in store for us.

Yes I know it passed (June 6th). Well, I can say that everything goes really well The new designer (mostly new code, based on the tech implemented in v2.x), underlying algo lib, drivers, code generator now takes ~9MB of C# code and is for 70-80% complete now. (you can model from scratch, add meta-data, refresh, validate, update meta-data from the model, create typed lists, typed views, sp calls, alter mappings etc. etc.. Currently we're testing the port of the code generation subsystem and after that it's DDL SQL generation time followed by the rest of the template studio elements being merged into the designer. I won't give a hard date when things are ready but it's definitely before the end of the year, otherwise we'll cut features, though I hope it won't get that far. As with the new designer, a lot of new features come to mind (e.g. model refactoring), it is to be seen how many of those we can add. Though it will be worth the wait.

Ok, thanks for info. I can do the interface thing I guess. As I have partial classes for every one of the subtypes, I will just put the interface on the partial class line rather than putting it in that LLBLGen designer section....same effect, right?

I am really looking forward to your new version and if end of year is target, I know we will start seeing some real info on it in the next 2 months and a beta within the next 3 as we less than 5 months from year end.

Cannot wait.

WayneBrantley wrote:

Ok, thanks for info. I can do the interface thing I guess. As I have partial classes for every one of the subtypes, I will just put the interface on the partial class line rather than putting it in that LLBLGen designer section....same effect, right?

Yes, same effect. With the designer approach, you get the type generated into the generated code, so you're forced to implement it to make the code compile. But it indeed would be the same.

I am really looking forward to your new version and if end of year is target, I know we will start seeing some real info on it in the next 2 months and a beta within the next 3 as we less than 5 months from year end. Cannot wait.

With before the end of the year, I was talking about the start of the beta period.