Home
Help
Register
Log in

Search

 
   Active Threads  

You are here: Home > LLBLGen Pro > LLBLGen Pro Runtime Framework> Target-per-Hierarchy Inheritance and 1:1 relationships
 

Pages: 1
LLBLGen Pro Runtime Framework
Target-per-Hierarchy Inheritance and 1:1 relationships
Page:1/1 

  Print all messages in this thread  
Poster Message
KL
User



Location:

Joined on:
31-Aug-2006 19:04:19
Posted:
11 posts
# Posted on: 11-Jan-2007 17:24:14.  
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...)
  Top
bclubb
User



Location:
Norman, Oklahoma
Joined on:
12-Feb-2004 22:18:04
Posted:
934 posts
# Posted on: 12-Jan-2007 02:34:39.  
If the ContactId is unique why can't it be the PK alone? Otherwise the workaround you have is what I would recommend.

  Top
KL
User



Location:

Joined on:
31-Aug-2006 19:04:19
Posted:
11 posts
# Posted on: 12-Jan-2007 02:40:19.  
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 Dissapointed
  Top
Walaa
Support Team



Location:

Joined on:
21-Aug-2005 16:03:48
Posted:
14569 posts
# Posted on: 12-Jan-2007 08:56:51.  
Your solution is the first thing that comes to mind, the simplest one.

  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37803 posts
# Posted on: 12-Jan-2007 10:45:24.  
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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
KL
User



Location:

Joined on:
31-Aug-2006 19:04:19
Posted:
11 posts
# Posted on: 12-Jan-2007 16:22:20.  
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)


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37803 posts
# Posted on: 12-Jan-2007 21:34:23.  
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.
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Andrei
User



Location:

Joined on:
19-Jan-2007 05:04:58
Posted:
7 posts
# Posted on: 30-Mar-2007 23:22:28.  
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?

  Top
Andrei
User



Location:

Joined on:
19-Jan-2007 05:04:58
Posted:
7 posts
# Posted on: 30-Mar-2007 23:42:17.  
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.
  Top
Andrei
User



Location:

Joined on:
19-Jan-2007 05:04:58
Posted:
7 posts
# Posted on: 31-Mar-2007 01:42:01.  
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.


  Top
Otis
LLBLGen Pro Team



Location:
The Hague, The Netherlands
Joined on:
17-Aug-2003 18:00:36
Posted:
37803 posts
# Posted on: 31-Mar-2007 11:13:42.  
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).
Frans Bouma
LLBLGen Pro / ORM Profiler Lead Developer | Blog | Twitter
 
Top
Pages: 1  


Powered by HnD ©2002-2007 Solutions Design
HnD uses LLBLGen Pro

Version: 2.1.12172008 Final.