Columns are missing in model store with TargetPerEntityHierarchy

Posts   
 
    
Posts: 36
Joined: 19-Dec-2022
# Posted on: 10-Jun-2024 11:57:09   

Hi,

we're using LLBLGen 5.10.2, but I tested this on 5.11.1, too.

In the designer using model first approach you have:

  • a super type entity
  • multiple sub type entities
  • hierarchy type "Target per Entity Hierarchy"
  • Postgres model data storage

When you now run "sync with the model" I would expect that in the Postgres database model all columns of the super type entity appear as well as all of the columns of each sub type entity. However it turns out that besides the super type columns only the columns of the first sub type are created in the target table. The columns of the other sub types are missing + the sub type entity field mappings all point to the first sub type column. Is this expected behavior?

I've attached an example LLBLGen 5.11 project where you can reproduce that.

Best regards, Markus

Attachments
Filename File size Added on Approval
Test.llblgenproj 14,865 10-Jun-2024 11:57.58 Approved
Walaa avatar
Walaa
Support Team
Posts: 14968
Joined: 21-Aug-2005
# Posted on: 11-Jun-2024 08:05:49   

Since the field has the same type in all subTypes, they are all mapped to the same field/column.

You can check this by going to the "Field Mapping" tab.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39689
Joined: 17-Aug-2003
# Posted on: 11-Jun-2024 08:54:36   

I think Markus refers to the fact that if you remove the generated table, and sync again, still just 1 field is added for the subtypes and all subtypes map to that field, instead of getting their own field.

The designer follows a simple rule for this, which is the same as when you map multiple entities onto the same target: it simply processes the entities as if they're mapped alone on that target. The reason is mainly that the alternative would lead to micromanagement settings where you have to specify which entity leads the table shape: is it the supertype, entity A, or maybe A and B are equal and C's field requires a different field...

There's no real solution for this, so we left this as-is.

Frans Bouma | Lead developer LLBLGen Pro
Posts: 36
Joined: 19-Dec-2022
# Posted on: 11-Jun-2024 11:33:13   

I'm sorry. The attached project file was misleading as was my description of the issue. Otis is right, I meant in fact the generation of the table during the sync.

If this is expected behavior/won't fix, I'm ok with it. These wrong mappings fortunately can be fixed manually or using a custom plugin and we have only one case where this occurs.

Thanks!

Walaa avatar
Walaa
Support Team
Posts: 14968
Joined: 21-Aug-2005
# Posted on: 12-Jun-2024 03:05:20   

Yes, this is the expected behavior.