Actually (and I forgot to mention that), Load is the correct method in this case, as it doesn't go to the DB and you're sure it exists. If a property of Product other than Id was accessed, NH would correctly retrieve it from the DB.
Diego On Sat, Apr 24, 2010 at 10:43, Jason Dentler <[email protected]> wrote: > 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]<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.
