Hi,

I have the following scenario:

So, I use one table with the following schema... ContactID, ModifierID, Description, Deleted

ContactID is a foreign key to another table ModifierID is a foreign key to another table as well (ContactID, ModifierID) pair is a primary key

I am using the ModifierID as the descriminator for my inheritance...

So, each contact (referenced by ContactID), should have a 1:1 relationship with any given subentity of the table described above since (ContactID, ModifierID) is the PK and ModifierID is the descriminator.

However, this is not the case... The relationship between Contact and subclass(es) is 1:n, I assume it works out this way because LLBLGen recognizes that (ContactID, ModifierID) as the PK and thus, there could be multiple entities and does not take into account the fact that because I'm using Target-per-Heirarchy inheritance and ModifierID as the descriminator.

Is there a way to get that 1:1 relationship I'm looking for?

Alternatively, I can create a property in the generated code to just return the first entity within the collection of the subentity, but it would be nice if I could do this without adding this custom code (it's not a big deal, just a design preference i guess...)

If the ContactId is unique why can't it be the PK alone? Otherwise the workaround you have is what I would recommend.

well, the "modifierID" is a foreign key to another table, and I want the combination of ContactID and ModifierID to be unique...

I guess i'll just continue to implement it the way I described if no one has any better suggestions

Your solution is the first thing that comes to mind, the simplest one.

It's not recommended to use an FK as the discriminator column. The reason is that if you change the FK field, the type changes, which is not workable, as that could create big problems in your database later on: it could be that the data is relational-model-wise correct but semantically it doesn't make sense.

Otis wrote:

It's not recommended to use an FK as the discriminator column. The reason is that if you change the FK field, the type changes, which is not workable, as that could create big problems in your database later on: it could be that the data is relational-model-wise correct but semantically it doesn't make sense.

I'm not sure I fully understand the concern. But the FK points to a PK that's not an identity, so the FK fields should always retain the same values (even after the DB is recreated or whatever)

KL wrote:

Otis wrote:

It's not recommended to use an FK as the discriminator column. The reason is that if you change the FK field, the type changes, which is not workable, as that could create big problems in your database later on: it could be that the data is relational-model-wise correct but semantically it doesn't make sense.

I'm not sure I fully understand the concern. But the FK points to a PK that's not an identity, so the FK fields should always retain the same values (even after the DB is recreated or whatever)

You could set the referenced related entity to a new related entity, and by that the discriminator column's value changes, while you have the same entity instance (object) in memory. That's incorrect.

I guess this would be a good thread to post my question. The only difference in my scenario is that ModifierID would not be an FK, but the combination of CustomerID and the ModifierID would be a primary key, and the relationship should be 1:1. I still can't figure out how to create subtypes using a discriminator column. When I try to do it, I am presented with a dialog where I have to select a discriminator column and two discriminating values, one for the super type, another is for the subtype. Why do I need one for the supertype?

Never mind my previous post. I believe I figured it out. The UI is a bit confusing though. I think you should put a check box in the dialog where you define a subtype for the super type indicating whether the supertype is abstract or not, and if it is, then do not require a discriminator value for it (at least that what led me to a confusion). Also making a type abstract is only possible after you create a hierarchy, am I correct? So, I entered a discriminator value FOO for the supertype, which never suppose to show up in the database, right?

Thank you.

Now I have a question regarding the use of the generated code. I guess GenPro does not recognize the fact that the column which is used as a discriminator together with the foreign key comprises the primary key for the table that stores my super-type objects, which means 1 to 1 relationship to the parent table. Is there any way for me to provide this knowledge in the project? Because all I can see in my generated code is the collection of super-type objects (abstract in my case) as a member of the parent object. Ideally, I would like to see references to the instances of my super-types. The way I can see dealing with this issue is to manually extend the parent class with those references and initialize them using filtering based on GetEntityTypeFilter predicate. Is there an easier way?

Thank you.

Do not hijack threads with your new questions, start a new thread please. See our guidelines for posting here: http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=7725

(we can't split threads in the forum at this point, so I can't do that for you).