Using v4.2 Final August 2nd 2015 build.

For a target per entity hierarchy it is not possible (anymore) to select the discriminator field to be part of the PK.

For entities that already have this defined the discriminator field is shown in the Identifying fields textbox, but after selecting Edit the field is not shown.

Any reason for this?

For entities that already have this defined the discriminator field is shown in the Identifying fields textbox, but after selecting Edit the field is not shown.

I don't understand this part, could you please provide screen shots.

Walaa wrote:

I don't understand this part, could you please provide screen shots.

Sure.

In an earlier version of the designer I have selected all 3 fields for the PK, but now when I select edit the window only shows 2 fields and the discriminator field is left out.

Reproduced with the latest v4.2 build. Steps:

1. Edit an entity (say 'Employee'). Select two fields for 'Identifying fileds' (say Id, Id2).
2. Make some entity (say 'Clerk') the sub-entity of 'Employee' in TPEH inheritance.
3. Define 'Id2' for the discriminator field and set the discriminator values for Employee and Clerk.
4. Go an Edit 'Employee' and try to change the 'Identifying Fields', the Id2 is not present in that list.

In step (4), if you destroy the TPEH inheritance, then the field appears in the 'Identifying fields' list again. We will check to see whether this is by design or not.

Having a filter on discriminator for identifying fields is in place since 2009, so since 3.0.

Having the discriminator value in the PK is unwise. We're planning to remove the discriminator value in the ctor in the runtime in v5. One of the reasons is that the discriminator value shouldn't be known nor settable from the outside. Having it in the pk however will make you be able to set the discriminator value for an entity, by specifying it in the pk. But that should never happen: it's a value directly specified through the type of the entity class, not the PK.

What I do acknowledge is the way filtering is lacking here: there is filtering in place for identifying fields not being able to be a discriminator column, but there isn't one on the set of potential discriminator fields. There's also a lack of validation in this area: it doesn't validate on whether an identifying field is a discriminator field.

Both issues will be addressed in v5.0

Otis wrote:

Having a filter on discriminator for identifying fields is in place since 2009, so since 3.0.

Is it already that long since I created these tables

Otis wrote:

Having the discriminator value in the PK is unwise.

I find it very handy to guarantee the records are unique for each descendant.

Otis wrote:

Both issues will be addressed in v5.0

Since I'm using this feature in a lot of tables I won't be able to update to v5.0 in the near future then

twaindev wrote:

Otis wrote:

Having a filter on discriminator for identifying fields is in place since 2009, so since 3.0.

Is it already that long since I created these tables

Otis wrote:

Having the discriminator value in the PK is unwise.

I find it very handy to guarantee the records are unique for each descendant.

Why not use an identity pk then? Values are guaranteed to be unique per table per DB. Having the discriminator in the PK suggests the values for other fields can be the same in multiple rows and the discriminator is used to make the rows unique. This is precisely what's wrong with it: you then have effectively multiple entities with the same semantic pk value, differentiating only by type.

Otis wrote:

Both issues will be addressed in v5.0

Since I'm using this feature in a lot of tables I won't be able to update to v5.0 in the near future then

It's a loophole in v2.6 which is not really commonly used in v3.0+ users, as the designer doesn't allow pk fields to be discriminators. (though discriminator fields be pk fields as you have found out) I'd look into having normal pk fields without the discriminator value, so e.g. using identity fields. If you already use an identity field in the pk, you can simply remove the discriminator from the identity fields and that's it.

Is there a particular reason why you need to use this and can't use another Pk scheme?

I'll try to explain with an example.

I have an order table with a simple identity PK and a table (TPEH) containing different kinds of references where the PK consist of the orderid, a type (disc.) and a text (in that order). Sometimes the same text is used for different kinds of references (don't ask me why), so the type is needed to make the PK unique.

Sometimes I want to have the references of a certain type and other times I need simply all references. This is where IMO inheritance is ideally suited for. In code I can simple refer to "References" or "TypeAReferences", "TypeBReferences", etc.

I use this concept in several ways and it has proven to be very efficient in both storage and performance (because the discriminator is part of the PK).

Of course I can put the different kinds of references in separate tables, but that requires multiple joins (especially when searching for orders by whatever reference).

As the discriminator field is already read-only why not just omit it as parameter in the entity's constructor (as it is ignored already) and re-enable it to be part of the PK?

Good points.

We're thinking to go this route: it's 'allowed' but with a warning (you can ignore warnings in the designer so it's not a big deal) that it can backfire. We'll not filter out discriminator fields in PKs anymore, so the problem you described in this thread won't happen anymore.

Komt goed!

Nogmaals dank je wel

BTW In the past I requested an option to reorder the fields in the PK.

Will this be in v5?

This also can be done in the scripts, but it would be nice to have it in the designer.

Fijne avond!

twaindev wrote:

BTW In the past I requested an option to reorder the fields in the PK.

Will this be in v5?

This also can be done in the scripts, but it would be nice to have it in the designer.

Fijne avond!

Field ordering is applied over the entire entity. You can define the order yourself, using this field ordering. See http://www.llblgen.com/documentation/4.2/Designer/hh_goto.htm#Functionality%20Reference/FieldOrdering.htm

This thus means you can order the pk fields in any way you wish.

I overlooked that this also determines the order of the fields in the PK.

Although I would like it more if the order of the fields in the PK was independent of the order in the table it is no big deal.