Patrick, For the sake of argument, let's say join could be used in the way you described. For the record, it looks like a classic many-to-many setup. So you end up with a larger entity that contains information for both Person and User. There's nothing on your setup that enforces or even implies as 1-to-one relationship, so let's imagine that a Person (let's call her Anne) has ended up with multiple users (ajepst and aepstein) mapped in the AdPerson table. Here's a mockup of what the two joined objects would look like:
AdPerson #1 AdPersonID : 1 PersonID: 5 PersonName: Anne UserID: 25 UserLogin: ajepst AdPerson #2 AdPersonID: 2 PersonID: 5 PersonName: Anne UserID: 26 UserLogin: aepstein Then, we imagine that we can modify and save each of these objects, just like any other normal nhibernate-connected object (unlike a projection, for instance) . Let's say we change my name in object AdPerson #1 AdPerson #1 AdPersonID : 1 PersonID: 5 PersonName: *Princess Leia* <= look, my new name! UserID: 25 UserLogin: ajepst Well, that's great.. but object AdPerson #2 is still around, with this data: AdPerson #2 AdPersonID: 2 PersonID: 5 PersonName: Anne UserID: 26 UserLogin: aepstein a) this is now weird and inconsistent, (I have two different names depending on which object I look at?) and b)... What happens if we were to give me a *different* new name in AdPerson #2? My awesome Leia name gets clobbered. awww. This object is identified by AdPerson #2 and using that to understand "sameness". There's no concept of "well keep track that THIS PART of this object over here is a part of this other object over here, and keep them in sync" .Net can handle this easily with whole objects, that's what Equals is about. But this partial stuff... well, in fact, AdPerson #1 and Adperson #2 aren't really the same idea, and if you did mysteriously change the data in one when you changed it in the other, it would weird, and would probably cause a lot more confusion than it would solve problems. The core issue is just that in this situation, NHibernate doesn't understand that these two objects are partially the same thing, and it doesn't have a good way of knowing that. The designers of NH decided to avoid the whole mess by restricting join to a true one-to-one. That way, duplicate Persons can't show up in conceptually different objects. If it's there, they are also the same object. simple. Note, if this IS something you want, you could try to implement it, but you'd have to figure a way around the intrinsic problems described above. Me, I'll stick to walking the relations when I need to for this kind of many-to-many layout-NHibernate allows a little bit of divergence from the db structure, but you still want to stay fairly close or you're going to be in some serious pain.. Good luck. On Wed, Sep 30, 2009 at 9:15 AM, Patrik Lowendahl < [email protected]> wrote: > Bump > > > On Wed, Sep 23, 2009 at 10:40 AM, Patrik Lowendahl < > [email protected]> wrote: > >> Is there any plans on supporting joins mapping on any other column then >> the class PK? >> >> I see a lot of legacy where they have used arbitrary columns as the FK, >> like this example: >> >> [Person] >> PersonId >> >> [AdPerson] >> PersonId >> ObjectSID >> >> [User] >> ObjectSID >> >> Doing a projection over this (UserInfo) becomes bothersome and the >> simplest solution would be something like: >> >> <class name="AdPerson"> >> ... >> <join table="Person"> >> <key column="PersonId" /> >> ... >> </join> >> <join table User> >> <key column="ObjectSID" foreign-key="ObjectSID" /> >> --- >> >> For the record, I don't agree with the database model, but this is what I >> have to work with and a construct like the above would make it a lot more >> easy to manage. >> >> -- >> Patrik > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
