Yep. Like Diego said, you can get away with that. In memory, Product.Prospects will be incorrect, but it sounds like you don't care about that.
I might be wrong, but you could also get away with a Load of Product instead of a Get, which saves you a SELECT, as long as you don't use the Product. If you have a proper db foreign key constraint to ensure Prospect.ProductId is valid, I think this is safe. Basically, you can get away with a LOT if you throw away the objects after the save. On Sat, Apr 24, 2010 at 6:33 AM, Diego Mijelshon <[email protected]>wrote: > 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]<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.
