So, in facr...if I know what I'm doing, it can work?! I am asking for another reason, I've built some time ago an automatic fetcher and binder of entities based on form post data...basically if you have in your form the following fields:
Prospect.Id Prospect.User.Id Prospect.Order.Id it will load object from db "Prospect" by its id in "Prospect.Id", then proceed to load and assign its children..."Prospect.User", load it by looking at "Prospect.User.Id" field, "Prospect.Order", by looking at "Prospect.Order.Id" field. now, if the Prospect.User and Prospect.Order are different than the originally assigned ones, then on commit of transaction this will be triggered automatically as an Update statement(s). My question to myself now was, what to do in this step "load and assign"...assign it on both ends or just one (e.g. assign it only on Prospect.User, or also on User.Prospects)...this gets more complicated if I have a Set on the other side, which requires another load or an eager load of all "User.Prospects". Do you understand my dilema? Vladan On Apr 23, 10:26 pm, Jason Dentler <[email protected]> wrote: > Vladan, > > RDBMSs don't have a concept of bi-directional one-to-many. Many to one > relationships don't exist in the database separate from the one to many. As > you pointed out, in our object model, we can have differences between the > one to many and the many to one. > > To handle this mismatch between what we can do with the object model and > what the database will allow, NHibernate fakes it. It only looks at one of > the object model relationships (either the one-to-many or the many-to-one) > when it stores the database relationship. > > We have inverse="true" in our mappings to tell NHibernate to look at "the > other side" when storing the relationship. > > In your object model, It's best just to maintain both sides of the > relationship so you don't have to worry later if it's set properly. Like > Roger pointed out, create a simple method that sets both sides of the > relationship. > > Thanks, > Jason > > On Fri, Apr 23, 2010 at 2:15 PM, Vladan Strigo <[email protected]>wrote: > > > > > > > I mean when adding/removing them.... > > > by all docs it says when tying them initially together that you must > > do: > > > entity1.entity2 = newEntity2 > > newEntity2.Entities1.Add(entity1) > > > but when I look at the nh profiler, it still does the update in the db > > if I only do this: > > > entity1.entity2 = newEntity2 > > > (so tie it only on one end) > > > so, I am wondering...how come it works?! and what are the cases where > > it doesn't? > > > Vladan > > > On Apr 23, 3:15 pm, Roger Kratz <[email protected]> wrote: > > > Do you mean when loading a bidirectional ref? No, you don't need to "tie" > > them together. You need to map both ends though - search for "bidirectional" > > in the docs. > > > > Do you mean when adding/removing items in a bidirectional ref in your > > domain/RAM? Yes, luckily. IMO POCO/PI is a good thing. You can help yourself > > writing something like someNewUser.Add(prospect) though and set both ends > > there. > > > > Do you mean when having a unidirectional ref? No, not at all. > > > > -----Original Message----- > > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Vladan Strigo > > > Sent: den 23 april 2010 14:02 > > > To: nhusers > > > Subject: [nhusers] Re: why do we need to connect relation on both side of > > related entites? > > > > anyone? > > > > On Apr 23, 11:04 am, Vladan Strigo <[email protected]> wrote: > > > > So I have a typical one to may: > > > > > Prospect...has *one* User > > > > > User...has *many* Prospects > > > > > I do a load of Prospect, load of an "User"...then tie them together: > > > > > Prospect.User = someNewUser > > > > someNewUser.Prospects.Add(Prospect) > > > > > My question is...why is this second part needed? I've seen it in books > > > > over the years as a textbook example, but also seen that it works > > > > without it sometimes. > > > > > So I am confused, do I need to connect the relation on both sides, and > > > > if so...why?! > > > > > Thanks! > > > > Vladan > > > > > -- > > > > 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]<nhusers%[email protected] > > > > > . > > > > For more options, visit this group athttp:// > > groups.google.com/group/nhusers?hl=en. > > > > -- > > > 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]<nhusers%[email protected] > > > > > . > > > For more options, visit this group athttp:// > > groups.google.com/group/nhusers?hl=en. > > > > -- > > > 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]<nhusers%[email protected] > > > > > . > > > For more options, visit this group athttp:// > > groups.google.com/group/nhusers?hl=en. > > > -- > > 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]<nhusers%[email protected] > > > > > . > > For more options, visit this group at > >http://groups.google.com/group/nhusers?hl=en. > > -- > 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 > athttp://groups.google.com/group/nhusers?hl=en. -- 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.
