Hi,

I have 2 questions:

1) How can I delete relation and/or fields on relations that was automatically generated from the database schema?The only option that I have is that I can only turn its hide flag.

2) When I create subtypes for my base entity (using the discriminator field) I would like that my new subtypes have some base fields which are inhereited from the base entity and additional various fields on relations and these fields on relations should not exist in the base entity. They should be only in sub types. Now the question: How can I do that in LLBGen 2.0?

Thank you very much, Best Regards

Michael

1) How can I delete relation and/or fields on relations that was automatically generated from the database schema?The only option that I have is that I can only turn its hide flag.

Using the Relations Tab, you can hide a relation either on the current entity or on both sides, (both entities of the relation). Hiding a relation on an entity, automatically hides the field mapped on this relation. To hide a relation, just select a relation and right-click to toggle its hidden flag. Or select an option from the "Actions On Selected Relations" drop down list.

Now you can leave the relation unhidden, and hide the field mapped on it, using the Fields On Relations Tab. To hide a field on a relation, select the field from the list and toggle the Hide checkbox.

2) When I create subtypes for my base entity (using the discriminator field) I would like that my new subtypes have some base fields which are inhereited from the base entity and additional various fields on relations and these fields on relations should not exist in the base entity. They should be only in sub types. Now the question: How can I do that in LLBGen 2.0?

In a TargetPerHierarchy for a SubType to have a field that's not mapped in the Parent Entity, this field should allow null in the database. Then you can open the subType entity properties in the Designer and go to the Fields Tab then go to the unmapped Fields sub-Tab, and map this field to the subType entity. And if this field was a FK, the corresponding relation will be mapped to the sub entity only and not to the Parent entity.

In a TargetPerHierarchy for a SubType to have a field that's not mapped in the Parent Entity, this field should allow null in the database. Then you can open the subType entity properties in the Designer and go to the Fields Tab then go to the unmapped Fields sub-Tab, and map this field to the subType entity. And if this field was a FK, the corresponding relation will be mapped to the sub entity only and not to the Parent entity.

Hi Walaa!

Thank you very much for the response! However my situation is that I have entity A which is a master and it has a details entity B. So far, B has the following field B.A_ID (which is nullabe) and as a result A has a reference (field on relation) to B A.B. Now, I would like that A will not have any reference to B, but all types that derive from A (A_child1, A_child2) will have refernce to B (A_child1.B, A_child2.B).

I could use your suggestions if the desire was to inhirit from B, but I would like to inherit from and all A subtypes should have reference to B while A which is a super (or base) entity should not.

Is there any solution for that in LLBLGen?

Thanks a lot in advance, Best Regards

Michael

Hi,

if you just want A_child1 to have a B property and not A, the only way is to define the relation at child level and not by inheritance.

A-----------A_Child2 | | | v A_Child1-->B

But you will need to do it for each child entity type.

Hi,

if you just want A_child1 to have a B property and not A, the only way is to define the relation at child level and not by inheritance.

A-----------A_Child2 | | | v A_Child1-->B

That's exactly what I would like to do. I don't want my child entities to inherit B propert from A because A should not have it at all.

But you will need to do it for each child entity type.

That's my 1000000$ question ! How can I practically do it in LLBLGen 2.0? Is TargetPerEntity the only option? Actually I don't like TargetPerEntity because I can find myself with a lot of unnecessary tables and of course I can suffer from the performance issues because of INNER JOINS which will be used in this case.

Is there any other way to create fields on relations on subtypes?

Thank you very much, Best Regards

Hi,

in your database you can create your field like this and use it in LLBLGen:

Table A

IDA(pk) ....

Table A_child1

IDA(pk/fk) IDB(fk) .....

Table A_child2

IDA(pk/fk) IDB(fk) .....

and TargetPerEntity will be applyed between A and A_child1 and A_child2.

Hi jbb,

Thnk you for the response This solution maps exactly what I need, however I have concerns about INNER JOINS that will be used to build these entities.

Actually, I prefer to implement TargetPerEntityHierarchy inheritance methodology, but I find that if I have many fields on relations, it is too complicated to hide them in Designer.

So, the question is if I can somehow hide/disable/unmap fiels on relations in my base/super entity (like unmapping of simple entity fields, which are nullable) and enable/map them in the derived subtypes?

Thank you, Best Regards

Inheritance will allow you to define a property in a parent object that will be inherited in a child object. If you want to have a property only in a child object, you have to define it in the child object and not in the parent because the .net object will use inheritance too.

Inheritance will allow you to define a property in a parent object that will be inherited in a child object.
If you want to have a property only in a child object, you have to define it in the child object and not in the parent because the .net object will use inheritance too.

This is exactly what I want. I would like to define a specific property only for child objects, but I want to use TargetPerEntityHierarchy. For example I have the following database schema (its diagramm is attached):

CREATE TABLE [dbo].[tblDepartments] (
    [Department_ID] [int] IDENTITY (1, 1) NOT NULL ,
    [DepartmentName] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [ManagedBy] [int] NOT NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblEmployeeTypes] (
    [EmployeeType_ID] [int] NOT NULL ,
    [EmployeeTypeDescription] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL 
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[tblEmployees] (
    [Employee_ID] [int] IDENTITY (1, 1) NOT NULL ,
    [EmployeeType_ID] [int] NOT NULL ,
    [Name] [varchar] (20) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [Address] [varchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL 
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[tblDepartments] ADD 
    CONSTRAINT [PK_tblDepartments] PRIMARY KEY  CLUSTERED 
    (
        [Department_ID]
    )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[tblEmployeeTypes] ADD 
    CONSTRAINT [PK_tblEmployeeTypes] PRIMARY KEY  CLUSTERED 
    (
        [EmployeeType_ID]
    )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[tblEmployees] ADD 
    CONSTRAINT [PK_tblEmployees] PRIMARY KEY  CLUSTERED 
    (
        [Employee_ID]
    )  ON [PRIMARY] 
GO

ALTER TABLE [dbo].[tblDepartments] ADD 
    CONSTRAINT [FK_tblDepartments_tblEmployees] FOREIGN KEY 
    (
        [ManagedBy]
    ) REFERENCES [dbo].[tblEmployees] (
        [Employee_ID]
    )
GO

ALTER TABLE [dbo].[tblEmployees] ADD 
    CONSTRAINT [FK_tblEmployees_tblEmployeeTypes] FOREIGN KEY 
    (
        [EmployeeType_ID]
    ) REFERENCES [dbo].[tblEmployeeTypes] (
        [EmployeeType_ID]
    )
GO

In addition I have several employee types, let's say regular, outsourcing and manager. Now, I would like to create 3 subtypes (RegularEmployeeEntity, OutsourcingEmployeeEntity and ManagerEmployeeEntity) on tblEmployees, which are derived from BaseEmployeeEntity using a TargetPerEntityHierarchy inheritance by EmployeeType_ID discriminator column and I want that only ManagerEmployeeEntity will have Departments collection. How can I do that in LLBLGen? The problem is that tblEmployee has relation with tblDepartments and as a result my BaseEmployeeEntity will also have Departments field on relation and this collection will be inherited by all 3 of the subtypes. How can I use the TargetPerEntityHierarchy and create Departments collection only for my 3 subtypes without having this collection in the base entity BaseEmployeeEntity?

Thank you very much, Best Regards

I understand what you need. But let's examine it at the database level. As LLBLGen Pro maps the database design to Objects and Entities.

So regarding the database design, there is no way to establish what you want unless you use a table for each type. (TargetPerEntity) That's the only to constrain the relation to subTypes and not to the Super Type Entity. And that's basicly what TargetPerEntity Hierarchies are used for.

Hi Walaa!

According to what you are saying, I need to create the following database design:

and in the LLBLGen I'll have the following model:

As a result, ManagerEntity will reference to DepartmentEntity collection. My concern is that if I want to implement such an hierarchy, I have to create a table with only one column which is its primary key - tblManagers table in my diagram.

• 1) Is not it overhead to create such a single column table? I can suffer from the performance issues because of the INNER JOINs...

• 2) Can you suggest me a better DB design or pattern that I can use to minimize the overhead in this case?

Thank you very much, Best Regards

Employee, manager etc. are a great hierarchy to explain inheritance . The hierarchy is also not that good for normal use. The thing is... you might run into the fact to have to alter the type of a live object/entity: when an employee gets promoted to manager.

So I'd suggest in this case to use a Role like element: employee which has the role 'manager' is a manager.

Or you could go the simpler route: an employee which is referred to by a department is a manager as that's implied by the relation.

That way you don't have the problem to change the type of an object which is in-memory or in the db.

Hi Otis!

Thanks for the respose

Employee, manager etc. are a great hierarchy to explain inheritance.

It is just a classic example Next time I'll use shape->triangle->etc... In the real life I have another types of entities.

The thing is... you might run into the fact to have to alter the type of a live object/entity: when an employee gets promoted to manager.

You are absolutely right. Employee can be promoted to manager (depends on his relations with another managers... ) However, lets say that in in my case employee or entity can't change its type.

So I'd suggest in this case to use a Role like element: employee which has the role 'manager' is a manager.

By saying that, do you mean mean that there should be table tblRoles and tblEmploye should have Role_ID discriminator column and then it is TargetPerEntityHierarchy?

Lets say that I have several, derived from the base entities and all of them have the same fields like their base, but the difference is in the fields-on-relations.

How can I build such a model in LLBLGen?

Of course, I can put the inheritance on a side and not use it, but I think that inheritance will make my code more clearer and I can use polymorphism. As I understand from you, I should reference my base entity to all the possible collections (fields-on-relations) and in the code I should check what type of entity I'm dealing with (using Role_ID) and then decide if I can work with a particular referenced collection or not, but why is it better than inheritance?

Thank you, Best Regards

Lets say that I have several, derived from the base entities and all of them have the same fields like their base, but the difference is in the fields-on-relations.

How can I build such a model in LLBLGen?

A possible solution is to map the table Employee twice (into 2 different entities) one called Employee where you hide the relation, the other called Manager where you keep the relation unhidden.

Thanks Walaa!

audiobird wrote:

Hi Otis!

Thanks for the respose

Employee, manager etc. are a great hierarchy to explain inheritance.

It is just a classic example Next time I'll use shape->triangle->etc... In the real life I have another types of entities.

The thing is... you might run into the fact to have to alter the type of a live object/entity: when an employee gets promoted to manager.

You are absolutely right. Employee can be promoted to manager (depends on his relations with another managers... ) However, lets say that in in my case employee or entity can't change its type.

It's good to use real data/names etc. for these kind of things. Now I have given you advice which doesn't fit your situation.

So I'd suggest in this case to use a Role like element: employee which has the role 'manager' is a manager.

By saying that, do you mean mean that there should be table tblRoles and tblEmploye should have Role_ID discriminator column and then it is TargetPerEntityHierarchy?

Changing a discriminator value is also changing a type so that's not useful. The way you should do it is to have a simple value with a lookup table (or if you use the numbers as enums in code, you can rely on that).

Lets say that I have several, derived from the base entities and all of them have the same fields like their base, but the difference is in the fields-on-relations.

How can I build such a model in LLBLGen?

If a subtype has a different relation, you have to define a table per entity, as the FK from the entity has to be placed in that subtype, not in the supertype (otherwise all entities inherit it). If the subtype entity is on the PK side, and you want to reference only that type from the FK side, you also need a different table for the subtype, otherwise it's not possible to determine which types to return if you fetch the related set.

Of course, I can put the inheritance on a side and not use it, but I think that inheritance will make my code more clearer and I can use polymorphism. As I understand from you, I should reference my base entity to all the possible collections (fields-on-relations) and in the code I should check what type of entity I'm dealing with (using Role_ID) and then decide if I can work with a particular referenced collection or not, but why is it better than inheritance?

Well, your situation doesn't run into the fact that you have to change the type of the entity, so I can't comment on that until I know what the real situation is.

Otis & Walaa!

Thank you very much for the ideas! Your support is extremely valuable and it is at the very high level... Now I can proceed with the design which will best fit my needs

Best Regards