For saving, you can get away with the latter, assuming that's the non-inverse side. Of course, the in-memory state of Prospect will NOT reflect that.
Diego On Sat, Apr 24, 2010 at 08:22, Vladan Strigo <[email protected]>wrote: > lets imagine a standard form to db scenario where you have related > entites (not what nh was meant to be, but nevertheless, it DOES > happen)... > > you have an entity called "Prospect", it has properties: > > - Name (string) > - Surname (string) > - InterestedInProduct (Product, many-to-one) > > > than you have an entity called "Product" which has: > > - Name (string) > - Code (int) > - Prospects (ISet of Prospect, one-to-many) > > > ok, now you have a form to edit a Prospect which has the following: > > - hidden input for Id (control id is: Prospect.Id) > - textbox for Name (control id is: Prospect.Name) > - textbox for Surname (control id is: Prospect.Surname) > - dropdownlist with all Products, and the current InterestedInProduct > is selected in the list, this represents the InterestedInProduct > propperty of the model (control id is: > Prospect.InterestedInProduct.Id) > > > now, you do a submit of the form, and on the server you do the > following (manually for starters): > > - you load the existing Prospect by Request.Form's "Prospect.Id" field > - you bind Name and Surname to the Prospect's properties > > and than an interesting thing needs to occur, we need to take from > Request.Form the "Prospect.InterestedInProduct.Id" field, do a > Session.Get<Product> with that value, and than > assign that loaded Product entity onto the Prospect we are currently > editing. > > we would typically do: > > var editingProspect = > Session.Get<Prospect>(Request.Form("prospect.id")); > editingProspect.Name = Request.Form("prospect.name"); > editingProspect.Surname = Request.Form("prospect.surname"); > > and than: > > editingProspect.InterestedInProduct = > Session.Get<Product>(Request.Form("prospect.interstedinproduct.id")); > > if I do a Session.SaveOrUpdate(editingProspect) and commit the > transaction it will successfully save this new relation in the > database. > > > My question is now, do I HAVE to do: > > var product = > Session.Get<Product>(Request.Form("prospect.interstedinproduct.id")); > editingProspect.InterestedInProduct = product; > product.Prospects.Add(editingProspect); > > (which does an additional load of all Prospects of this Product, > because its a Set and the whole duplicates thing) > > or could I get away with: > > var product = > Session.Get<Product>(Request.Form("prospect.interstedinproduct.id")); > editingProspect.InterestedInProduct = product; > > > and what the implications of doing so? > > > I am asking because I am working on automating this, and already if I > name my fields like I did above, I can just do: > > FetchAndBind(editingProspect); > > it will do all those actions mentioned above, and returned a prepared > object to be saved...my only question remains how to tie the > relations...how much is it obligatory on both sides ;) > > > > > Vladan > > > > > On Apr 24, 2:15 am, Jason Dentler <[email protected]> wrote: > > Yes. If you know what you are doing, you can usually get away with it. I > > still don't suggest it though. > > > > I don't really follow your process. You've lost me on which objects are > > persisted & loaded, which are persisted but not loaded, and which aren't > > persisted. Perhaps some code would make more sense. > > > > On Fri, Apr 23, 2010 at 7:02 PM, Vladan Strigo <[email protected] > >wrote: > > > > > > > > > > > > > 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]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > . > > > > > > > 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]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > . > > > > > > 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]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > . > > > > > > 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]> > <nhusers%[email protected]<nhusers%[email protected]>> > > > <nhusers%[email protected]<nhusers%[email protected]> > <nhusers%252bunsubscr...@googlegroup s.com>> > > > > > . > > > > > 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]<nhusers%[email protected]> > <nhusers%[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]> > <nhusers%[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]<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 at http://groups.google.com/group/nhusers?hl=en.
