Hi there

I have two tables that store somewhat generic data which is interpreted at runtime. Lets call one "PropertyBag", the other "Property". A property bag consists of various properties which are basically key-value pairs, e.g:

PropertyBag Type=PersonInfo PropertyKey: FirstName | PropertyValue: John PropertyKey: LastName | PropertyValue: Doe PropertyKey: BirthDate| PropertyValue: 1968.01.01

PropertyBag Type=MarriageInfo PropertyKey: MarriageDate | PropertyValue: 2007.01.01 PropertyKey: DivorceDate | PropertyValue: NULL

Other entites (e.g. a User) can have various property bags of various types (e.g. several _AddressInfo _property bags that contain properties like street and city names). When mapped to code, my property bags are _PropertyBagEntity _ instances that provide a bunch of _PropertyEntity _instances. However, I'd like to work with classes like _PersonInfo _or _MarriageInfo _that derive from _PropertyBagEntity _(rather than wrapping it) in order to provide convenience properties, validation etc.

In order to do that, I need LLBLGen to dynamically instantiate the correct class types (based on a given field value that provides a flag) when performing a fetch:

//returns an instance of type PropertyBagEntity
switch(myAttributeType)
{
  case AttributeType.PersonInfo:
    return new PersonInfo();
  case AttributeType.MarriageInfo:
    return new MarriageInfo();
  default:
    //fall back to generic base class
    return new PropertyBagEntity();
}

Is this possible and if yes, what's the recommended approach to inject this builder logic?

Thanks for your advice Philipp

Hi Philipp,

You can use TargetPerEntityHierarchy. To start please read LLBLGenPro Help - Using the designer - Inheritance mapping - Creating hierarchies of type TargetPerEntityHierarchy.

Also read the concepts section: LLBLGenPro Help - Concepts - Entity inheritance and relational models

daelmo wrote:

You can use TargetPerEntityHierarchy. To start please read LLBLGenPro Help - Using the designer - Inheritance mapping - Creating hierarchies of type TargetPerEntityHierarchy.

Also read the concepts section: LLBLGenPro Help - Concepts - Entity inheritance and relational models

Hi Daelmo

Thanks for your fast reply! I read the concepts, but they don't solve my problem yet:

• my discriminator field is a foreign key, because the definition of a property bag is stored in a different table in order to provide validation on the DB level, if required. Therefore, the designer doesn't allow me to select that field. As a note: I read the reason for this, but I think it's pretty artificial and forces me to introduce a hack in my database design. I wish I could switch this limitation off.

• If possible, I'd like to do the distinction in code rather than in the designer. It may very well be that my customer introduces a new PropertyBag into the database at a later time. It would be nice if they could just update a factory class and recompile their solution without having the need to get themselves familiar with LLBLGen and re-generate the DAL. I know this may sound awkward, but it would indeed simplify things remarkably. Is that possible?

Thanks again, Philipp

Well if you don't want to depend on the Designer, then you will need to create these subType classes yourself, to inherit from the PropertyBagEntity, and also you need to create a factory class to instantiate the correct type based on a switch case for some passed parameter.

Walaa wrote:

Well if you don't want to depend on the Designer, then you will need to create these subType classes yourself, to inherit from the PropertyBagEntity, and also you need to create a factory class to instantiate the correct type based on a switch case for some passed parameter.

Exactly - that's pretty much what I wanted to show with the dummy snippet in the original post However, I'm not sure what's the best approach here. Is it by overriding the PropertyBagEntityFactory class? Or doesn't this work in all cases (e.g. because the parameterless constructor is invoked) and I have to edit a template or a region in the generated code?

Cheers, Philipp

Is it by overriding the PropertyBagEntityFactory class?

This is the way, and you'll just have to include a parameterless constructor, for some XML deserialization routines.

Walaa wrote:

Is it by overriding the PropertyBagEntityFactory class?

This is the way, and you'll just have to include a parameterless constructor, for some XML deserialization routines.

Works like a charm - thank you