Yes it would, I know that...and in other cases Load saves the day pretty good.
However in this case, I am abusing the Multicriteria in a way that I first traverse the object...build up a list of query descriptors...then have a converter which converts them to ICriteria queries, after which its as simple as executing one multicriteria... Now I am only wondering whether to include in my query descriptors also the option which says...if list property on the other side is ISet, then load it eagerly. Thanks guys for brainstorming with me! :) Vladan On Apr 24, 4:37 pm, Diego Mijelshon <[email protected]> wrote: > 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 > > ... > > read more » -- 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.
