1 parent 100 child each with 10 grandchild 3 plain queries with PKs in the where instead GRAND JOIN with BIG-FAT tables.
The other way is Multi-Query, mimic the same behavior of batch-size... 3 queries with 2 round-trips On Thu, May 6, 2010 at 7:18 PM, Diego Mijelshon <[email protected]>wrote: > It's possible. But it's hard to tell what will work best at this stage. > > For the record, I use batch-size as my default approach, but I'm not sure > if that's the best in this case. Only an actual profiling of the app (which > should also consider things like caching) will tell what's best. > But again, we don't even know what the performance requirements of the app > will be, so... > > Diego > > > On Thu, May 6, 2010 at 18:32, Fabio Maulo <[email protected]> wrote: > >> In this case the eagerly load is not efficient. >> The best way to do it with fews round trips is using batch-size at >> collections (the amount of round trips depend on the size of batch-size). >> >> @DaveL >> To do it you don't need to write queries. Only get the parent and use it >> with an opened NH's session... NH will do the hard work. >> >> On Thu, May 6, 2010 at 5:25 PM, Diego Mijelshon >> <[email protected]>wrote: >> >>> First of all, NHibernate can handle cases like this perfectly, and with >>> very little effort. >>> But... you need to let it work. >>> You seem to come from a DB-oriented background, and you are thinking of >>> the SQL and roundtrips first (client side composition?), which is not the >>> best way to take advantage of NH's features. >>> >>> There are (at least) three steps for a good design: >>> - Define your classes (you already did). For better query possibilities, >>> make all relationships bidirectional. >>> - Create the queries for your use cases using a DAO or Repository >>> *without* thinking about microoptimization yet. You can start by returning >>> the parent and let the children/grandchildren collection lazy load >>> - Optimize. >>> >>> We could be getting a little ahead of ourselves... but the better >>> approach for optimization in this case probably involves 3 roundtrips >>> (parent, children, granchildren). The good news is, NHibernate can handle >>> that perfectly. >>> Here's one way of doing it: >>> http://ayende.com/Blog/archive/2010/01/16/eagerly-loading-entity-associations-efficiently-with-nhibernate.aspx >>> >>> Diego >>> >>> >>> >>> On Thu, May 6, 2010 at 09:23, DaveL <[email protected]> wrote: >>> >>>> Hi, >>>> >>>> I’m working on the design of a new project and I was considering using >>>> nHibernate as my ORM. However, I have a specific need and I’m unsure >>>> whether nHibernate can answer the call. >>>> >>>> I would like to do client-side composition. >>>> >>>> Given those premises: >>>> • I have the classes Parent, Child and GrandChild, with >>>> appropriate >>>> collection properties. >>>> • Each of those classes have a property Name. >>>> • I have already loaded a Parent called “parent1”. >>>> • “parent1” has 100 Child already loaded, with names “child1”, >>>> “child2”, …, “child100”. >>>> • No GrandChild is loaded yet. >>>> • Suppose each Child owns 10 GrandChild objects, although we don’t >>>> know it yet since GrandChild aren’t loaded yet, for a total of 1000 >>>> GrandChild. >>>> >>>> I want to load GrandChild objects, given the Parent’s Name “parent1”. >>>> What I want is to get all 1000 GrandChild from my web service and >>>> compose them client-side with my 100 Child objects based on the >>>> foreign key, because I don’t want to do 100 round-trips to the >>>> backend. >>>> >>>> If I was to write the SQL query for that, I would write something >>>> similar to the following: >>>> >>>> Select gc.Id, gc.ChildId, gc.Name >>>> From Parent p inner join Child c on p.Id = c.ParentId >>>> Inner join GrandChild gc on c.Id = gc.ChildId >>>> Where p.Name = “parent1” >>>> >>>> Then, I would compose each GrandChild object with its parent, using >>>> the ChildId foreign key. >>>> >>>> How would you resolve that problem with this nHibernate? >>>> >>>> Thanks! >>>> dave. >>>> >>>> -- >>>> 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. >>> >> >> >> >> -- >> Fabio Maulo >> >> -- >> 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. > -- Fabio Maulo -- 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.
