LLBLGen version 5.1.3 Adapter Platform: .NET 4.6.1 Language: C# Framework: DTO Class Model Preset: SD.DTOClasses.ReadOnlyDTOs SQL Server

I have a entity model with this structure:

Client (ClientId int PK, Name varchar(10)) Project (ProjectId int PK, Name varchar(10), ClientId int FK) Event(EventId int PK FK) (Event is a subclass of Project with the TargetPerEntity approach, so Event.EventId = Project.ProjectId) MealType (MealTypeId int PK, Name varchar(10), EventId int FK)

In other words, a MealType has 1 related Event, Event is a subclass of Project, and a Project has a 1 related Client.

I'm creating a Derived Model based on MealType. In the "Derived Element Sub-Element Selection" panel, I see the attributes of MealType, as expected. Under MealType, there is an "Event" subtree, as expected. In that subtree, there are all the fields from both Event and also from Project, which is as expected (since Project is the base class of Event). Also under the "Event" subtree are sub-subtrees for all the entities that are related to Event. However, only the Relationships for "Event" are shown - none of the relationships that come from the "Project" base class are listed. Specifically, the "Client" relationship isn't in the list.

As an experiment, I created a Derived Model based on "Event", and in that case there are subtrees in the designer for the relationships that are defined in "Event" and also those that are defined in "Project", so that's working as expected.

So, it seems that when creating a derived model, if the root entity has a relationship to another entity that's a subclass, then the subclass' base class relationships are missing in the designer.

Add a screenshot

We explicitly don't include related entities over inherited relationships in embedded derived elements, as is the case in your MealType derived model. When I enable it though, the resulting code doesn't really seem problematic (there are 2 cases with inheritance and the queries required to fetch the derived elements, hence these aren't supported, but this one doesn't fit this case). As in: the related 'Client' fields should be materializable at runtime. Our design documents don't explain this particular exclusion (only the two others).

I have to do some tests to see why it is excluded and document the case if it is needed to be excluded. Denormalization is limited in this case regardless, as you can't denormalize an inherited field, but that's logical.

We've found no reason to keep this restriction and it has been removed. This means the next v5.0.10 and 5.1.3 hotfix builds will have this restriction lifted and you should be able to model your derived models like you intended. These fixes will be released later today.

Please download the latest 5.1.3 hotfix for the fix. Thanks for reporting this!