Hi,

I have a file entity and that's a super type of an image entity.

tbl_file

FileID int pk FileName varchar

tbl_player_skin_image_value

PlayerID int pk ImageID int pk FileID int pk fk

I set the image table be a sub-type of file and the geenrated code is giving the following error.....

No overload for method 'FileEntity' takes '3' arguments

No overload for method 'FileEntity' takes '4' arguments

Rather strangely, the image entity has two constructors that are trying to pass integers to the file entity.

        public PlayerSkinImageValueEntity(System.Int32 playerId, System.Int32 imageId, System.Int32 fileId):base(playerId, imageId, fileId)
        {
            SetName("PlayerSkinImageValueEntity");
        }

        public PlayerSkinImageValueEntity(System.Int32 playerId, System.Int32 imageId, System.Int32 fileId, IValidator validator):base(playerId, imageId, fileId, validator)
        {
            SetName("PlayerSkinImageValueEntity");
        }

Any ideas? Cheers, Ian.

So it looks like you can only inherit from an entity that can be joined on the subtype's complete primary key.

The designer should surely enforce this?

Hi Ian, this is copied from manual (LLBLGenPro Help - Concepts - Entity inheritance and relational models - Hierarchy creation for proper entity relation modelling - Physical representation in the data model and LLBLGen Pro entities):

Don't use surrogate keys on the subtype tables, it's important the PK of the subtype tables has the foreign key to the supertype's PK.

LLBLGenPro Designer enforces this, as far as I know. What LLBLGenPro Designer Build are you using?

2.5 final.

Ian, Could you show me the steps you are following to make the subtype?

LLBLGenPro wrote:

To create a hierarchy of type TargetPerEntity, you have two options. One is the option to let LLBLGen Pro find all hierarchies of TargetPerEntity in the entities in the project. To start this option, right-click Entities in the project explorer and select Construct 'Target-per-entity' Hierarchies

LLBLGenPro wrote:

Another option to create a hierarchy of type TargetPerEntity is to build the hierarchy per entity. You activate this option by right-clicking an entity and then selecting the context menu option Make Sub-type of which will show you an entity type which is a candidate to be a supertype for the currently selected entity. See the screenshot below for an example.

I used method number 2. (Didn't even know about the other one)

Method one finds the same relationships. I just tried it.

I don't see why this isn't supported. I just did virtually the same thing with a prefetch, some fields mapped onto a related entity and an extra new.

2.5 final.

Please find the Designer's release date (Help -> About).

I don't see why this isn't supported. I just did virtually the same thing with a prefetch, some fields mapped onto a related entity and an extra new.

PrefetchPaths have nothing to do with Inheritance hierarchies.

As per the manual, in a target per entity inheritance hierarchy, the subType has to have the FK to the superType as its own PK. This is crucial to enforce uniqueness, and to prevent having more than one subTypeEntity refering to the same SuperType entity (i.e. enforcing 1:1 relation), otherwise it would be a m:1 refrential relation.

PrefetchPaths have nothing to do with Inheritance hierarchies.

PrefetchPaths did enable me to create the same functionality that I would've got with inheritance hierarchies.

In both cases you're requesting an entity and getting a related entity too.

As per the manual, in a target per entity inheritance hierarchy, the subType has to have the FK to the superType as its own PK.

This is crucial to enforce uniqueness, and to prevent having more than one subTypeEntity refering to the same SuperType entity (i.e. enforcing 1:1 relation), otherwise it would be a m:1 refrential relation.

Not if the FK has a unique constraint on it. In fact that's how I got the designer to recognize the inheritance relationship.

PrefetchPaths did enable me to create the same functionality that I would've got with inheritance hierarchies.

In both cases you're requesting an entity and getting a related entity too.

Well that's a flase feeling As in an inheritance hierarchy, the subEntity actually inherits properties of its super Entity. And there is no field to represent the super Entityu inside the sub Entity.

Manager.Name vs Manager.Employee.Name

Also when deleting, inserting, and updating, you only deal with one entity and the framework takes care of the underlying plumbing.

While in a prefetchPath scenario, you will have to issue 2 deletes to delete the Manager record first then delete the employee record. Same with inserting.

Not if the FK has a unique constraint on it. In fact that's how I got the designer to recognize the inheritance relationship.

I still want to know your designer release date

I've got the demo designer here at work. Its March 28th.

Has anyone had chance to look at this?

How about it, is there any chance that that an inheritance relationship can be recognized with just a unique constraint?

What you want can't be done, it's not supported, as explained earlier in this thread. The reason is that there has to be a 1:1 pk-pk relation between supertype and subtype, and that's not the case in your situation, as the pk has 3 fields in the subtype.

Why can't it be done with a 1:1 fk-pk relation where the fk has a unique constraint on it?

The designer's with me.

I can't reproduce what you're suggesting. I created your 2 tables. Made FileID in SkinImage an fk to File. I can't make SkinImage a subtype of File in the designer.

This is the expected behavior: the skinimage isn't a proper subtype of file, as I explained above, so it shouldn't be seen as a subtype.

What I wonder now is: how could you create skinimage to be a subtype of file, while I can't do that? I.o.w.: are the tables really setup like you've illustrated in your startpost?

Anyway, don't make skinimage a subtype of file, as it's not a unique pk-pk 1:1 relation.

Did you put the unique constraint on the fk?

If so then I'll see if I can send you a stripped down version of the project with just two entities in it.

Anyway, don't make skinimage a subtype of file, as it's not a unique pk-pk 1:1 relation.

The code doesn't compile anyway so I can't.

edit Perhaps using MySql makes a difference?

Ian wrote:

Did you put the unique constraint on the fk?

If so then I'll see if I can send you a stripped down version of the project with just two entities in it.

Anyway, don't make skinimage a subtype of file, as it's not a unique pk-pk 1:1 relation.

The code doesn't compile anyway so I can't.

edit Perhaps using MySql makes a difference?

I didn't put a UC on the FK, I'll try that. MySql doesn't make a difference, the designer works with uniform meta-data.

It's not supported so you've to remove the inheritance if you've still have it set. I'll see if I can repro it and if so, I'll add a restriction to the designer so it won't be popping up.

The routine checks if both sides are a PK but it doesn't check if the fields in the 1:1 relation are the WHOLE pk (which isn't the case). Your situation is the same as a non-PK FK with a UC, which is also a 1:1 relation. THis is currently also not supported.

It was indeed a bug in the routine which checks whether a relation is a valid hierarchy relation. Fixed in next build.

OK, cool. Does this need to be a bug? Is having a 1:1 in this way that different to implement than 1:1 where both sides are the full primary key?

Ian wrote:

OK, cool. Does this need to be a bug? Is having a 1:1 in this way that different to implement than 1:1 where both sides are the full primary key?

Yes actually it is, as the pk of the subtype requires more values which is odd considering the fact that the subtype's PK is actually the PK of the rootentity of the inheritance hierarchy: any other fields in the PK of a subtype are irrelevant and shouldn't be in the PK.

any other fields in the PK of a subtype are irrelevant and shouldn't be in the PK.

Could you create a distinction between the 'official' PK of the subtype and the column of the subtype that is used to link to the super type? This 'hierarchy' key could just be any column that's unique.

So there'd be a refactoring of the 'hierarchy' key concept away from the primary key.

Ian wrote:

any other fields in the PK of a subtype are irrelevant and shouldn't be in the PK.

Could you create a distinction between the 'official' PK of the subtype and the column of the subtype that is used to link to the super type? This 'hierarchy' key could just be any column that's unique.

So there'd be a refactoring of the 'hierarchy' key concept away from the primary key.

I understand what you're saying, but that's not going to work. Say you want to save a new subtype S. If you set the PK field, which is the PK field of the supertype, you can't save it, you also have to set the PK field of the subtype. Which is odd, as the entity inherits its PK from its supertype.

It's related to how hierarchies are modelled in a relational model: either in a single table, or in separate tables: both have specific characteristics, otherwise things might 'look' like they're forming an inheritance hierarchy, but actually they're not.

Say you want to save a new subtype S. If you set the PK field, which is the PK field of the supertype, you can't save it, you also have to set the PK field of the subtype. Which is odd, as the entity inherits its PK from its supertype.

I don't quite follow...

Lets say A inherits from B and A has more columns in its pk than B.

So I create a new A and set its primary key. B's primary key is just some sub-set of A's columns.

If I create a new B then I just set its primary key.

Why would I create a new B and try and save it as a new A? Yes an A inherits some of its state from a B, but it can add additional state too. Why shouldn't that additional state include adding to the sub-type's pk?

The PK of B is synced with the PK of A, as it's assumed that A's PK is the same as B's as A's a full subtype (thus in theory doesn't even have a PK, it's PK is in B, as it derives from B).

If you add additional PK fields to A, it goes wrong because you have 2 sources of PK fields. You therefore can't rely on the PK of B to obtain A's own data.

Sure, you'll now say that A's PK field related to B's PK field has a UC, though that means that A's PK is in fact that field, and all other fields in A's PK aren't needed (as the field related to B's PK is the one which makes the row in A already unique)