This is also an answer in part to Fabio Maulo. Very valid and good points. I understand the technical difficulties in what I suggest. I can't agree that this has to be a many to many though, let me explain.
There is several scenarios when modeling where entities will look different, a product will not always be a product in all contexts of a system. Product is a very good example of this. In a system (or actually a database) that handles both the PLM part of a company and order part, there will be inconsistency in how you model the subsystems. You do not want to reuse the Product entity from the PLM subsystem into your Order subsystem and often the shape of the information are different in the two contexts. In the PLM system you might want a very rich product entity while in the Order->OrderLine->ProductInfo case you want a very slim product. In some cases, and I have a couple of those scenarios in my current project, the business looks at the information a bit different in between these context. And I would argue that the model should look like the business looks at it, not as the database relational model has put it for one context (in this case the PLM). This is the case for my AdPerson / Person example (the real example is actually in three parts). The model that generated that table structure had requirements that made sense for that context. In the context I am right now it doesn't make sense, the business doesn't look at the entity in the same way. They want the information from both tables to be in the same entity, that is how that part of the business looks at it. Not as separate entities. -- Patrik On Wed, Sep 30, 2009 at 4:59 PM, Anne Epstein <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
