*NH-2316 <http://216.121.112.228/browse/NH-2316>* although the name of the jira is subselect, the actual patch lets a developer set the batch size for an entity\collection overriding the settings in the mappings.
looking forward for comments\application of the patch. thanks alot. On Thu, Sep 2, 2010 at 6:52 PM, nadav s <[email protected]> wrote: > its much more pretty that what needs to be done now to achive the same > result > > > On Wed, Sep 1, 2010 at 9:48 PM, Fabio Maulo <[email protected]> wrote: > >> Ups sorry you have already included the option for collection... >> As you can see, nadav, the work to do in each UoW will be pretty ugly than >> the batch-size by default in the mapping... >> I would see how you will manage it in your application where, hopefully, >> the session is managed in a generic way not depending on a specific >> use-case. >> >> >> On Wed, Sep 1, 2010 at 3:42 PM, Fabio Maulo <[email protected]> wrote: >> >>> Not enough... it should allow the batch-size per collection >>> (property-path) not only per-class. >>> >>> >>> On Wed, Sep 1, 2010 at 3:19 PM, Diego Mijelshon >>> <[email protected]>wrote: >>> >>>> If you do implement a customizable batch-size, it should be >>>> per-session... >>>> Something like the existing SetBatchSize and EnableFilter... >>>> >>>> A possible API: >>>> >>>> session.EnableBatching(typeof(Foo), 100); //on Foo entity >>>> session.EnableBatching(typeof(Foo), "Bars", 50); //on the Foo.Bars >>>> collection >>>> session.EnableBatching("Foo.Bars", 50); //alternative >>>> session.DisableBatching(...); //with the same options >>>> >>>> Diego >>>> >>>> >>>> >>>> On Wed, Sep 1, 2010 at 14:38, nadav s <[email protected]> wrote: >>>> >>>>> of course i'll be doing the same work as batch size, i'm not set to >>>>> implement batch size all over again, but trying to allow it to be query >>>>> specific, meaning, being able to look for owners of a specific query, and >>>>> not all owners that are in the session (owners from different query might >>>>> be >>>>> there), and allowing it to be overrideable >>>>> >>>>> >>>>> On Wed, Sep 1, 2010 at 8:09 PM, Fabio Maulo <[email protected]>wrote: >>>>> >>>>>> ah... >>>>>> take care with "using IDs is more efficient" because "subselect" does >>>>>> not suffer the problem of max-parameter (IIRC 2100 in msSQL) >>>>>> >>>>>> >>>>>> On Wed, Sep 1, 2010 at 2:03 PM, nadav s <[email protected]> wrote: >>>>>> >>>>>>> great. thanks >>>>>>> >>>>>>> >>>>>>> On Wed, Sep 1, 2010 at 7:56 PM, nadav s <[email protected]> wrote: >>>>>>> >>>>>>>> you know the internal of nhibernate much much much better than me, >>>>>>>> and i won't get into an implementation argue with you, but it is >>>>>>>> possible to >>>>>>>> implement. >>>>>>>> >>>>>>>> with subselect (again i'm talking about subselect because i didn't >>>>>>>> do any research on the batch size, but i guess the idea is similar >>>>>>>> because >>>>>>>> it works the same, only batch size issues a good query and subselect >>>>>>>> issues >>>>>>>> an evil one), as i've noticed, there is a special one-to-many >>>>>>>> collection >>>>>>>> persister, that knows once the collection is accessed, use a sub select >>>>>>>> batcher that loads the collections of all the owners that were >>>>>>>> returned by >>>>>>>> the initial query. >>>>>>>> >>>>>>>> if the persister could have been set, or modified, for a specific >>>>>>>> instance of a collection, it would have been possible - you could have >>>>>>>> set >>>>>>>> the batch size\subselect for a specific query, which in turn would >>>>>>>> have set >>>>>>>> a different persister for the collections that their persisters needs >>>>>>>> modification, and then when a collection would have been accessed, the >>>>>>>> persister would have done its thing. >>>>>>>> >>>>>>>> of course, i'm not sure thats the proper way of implementing it, but >>>>>>>> as an idea - tell the specific collections that are created for the >>>>>>>> entities >>>>>>>> of a specific query to do something else than the default, it is >>>>>>>> possible >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Sep 1, 2010 at 7:49 PM, John Davidson <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> I think nadav is saying that subselect from NHibernate is an issue, >>>>>>>>> but the implementation he is proposing will fix that problem >>>>>>>>> >>>>>>>>> John Davidson >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Sep 1, 2010 at 12:46 PM, Fabio Maulo <[email protected] >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> LOL!! >>>>>>>>>> Your first assertion : "btw, i don't really get what is the >>>>>>>>>> problem with subselect" >>>>>>>>>> Your second assertion : "the sub select is always inefficient" >>>>>>>>>> >>>>>>>>>> On Wed, Sep 1, 2010 at 1:42 PM, nadav s <[email protected]>wrote: >>>>>>>>>> >>>>>>>>>>> the sub select is always inefficient, especially when there is an >>>>>>>>>>> initial complex query (with sub queries in it), and its a killer >>>>>>>>>>> when its a >>>>>>>>>>> two level tree (when fetching the grandchildren). fixing it was >>>>>>>>>>> really >>>>>>>>>>> really easy, and i can't see any downside to it. >>>>>>>>>>> >>>>>>>>>>> different use cases in a web app: >>>>>>>>>>> >>>>>>>>>>> use case 1: sub select\batch size is NOT desired >>>>>>>>>>> >>>>>>>>>>> the user searches for car companies by some criteria. the user >>>>>>>>>>> will then choose (double click on a grid's row or something) one of >>>>>>>>>>> the >>>>>>>>>>> companies to see it in full details. each company has >>>>>>>>>>> one-to-many car types (mazda -> mazda 3, mazda 5, mazda 6...) and >>>>>>>>>>> each >>>>>>>>>>> car type will be displayed in its own tab, when at first, the >>>>>>>>>>> newest car type or the most expensive one, doesn't matter is >>>>>>>>>>> selected. >>>>>>>>>>> each car type has its models, mazda3 2008 isn't the same as >>>>>>>>>>> 2010 (i don't that much about cars and not sure the years are >>>>>>>>>>> correct, >>>>>>>>>>> but there are differences between the models). >>>>>>>>>>> >>>>>>>>>>> the result: if carType.Models is mapped with some batch size, >>>>>>>>>>> say 10, the models of 10 of the car types are now fetched, although >>>>>>>>>>> the user only watches the models of one of the car types, if >>>>>>>>>>> there could be lots of models for each car type, it slowed the >>>>>>>>>>> first tab, >>>>>>>>>>> and made the other tabs faster, because their car types are >>>>>>>>>>> now loaded, but its not what is desired, because the user is >>>>>>>>>>> expected to >>>>>>>>>>> click on only one of other tabs or something. >>>>>>>>>>> >>>>>>>>>>> use case 2: desired: >>>>>>>>>>> >>>>>>>>>>> the user wanna see some custom developed report (ui that can >>>>>>>>>>> be implemented with MRS/Cognus or any other reporting framework, >>>>>>>>>>> and we have all kinds of reports that live up to this >>>>>>>>>>> definition, and for some good reasons also). for the report the user >>>>>>>>>>> searches for >>>>>>>>>>> car companies by some criteria (some search form) and then >>>>>>>>>>> expects to see the returned companies, paged of course, but with all >>>>>>>>>>> of their car types, and for each of the car type - all of its >>>>>>>>>>> models. here, a sub select or batch fetching is a must or else >>>>>>>>>>> we'll get a >>>>>>>>>>> CP >>>>>>>>>>> with join fetching, or N^2 + 1 if we do regular lazy loading >>>>>>>>>>> (like we wanted to do in the first situation). >>>>>>>>>>> >>>>>>>>>>> of course we can work around that, and thats exactly what we do, >>>>>>>>>>> using a generic mechanizm that for reports, eager fetches with sub >>>>>>>>>>> selects >>>>>>>>>>> and not joins, the association it was asked to fetch. for the >>>>>>>>>>> regular >>>>>>>>>>> queries, it just use the default which is regular lazy. >>>>>>>>>>> >>>>>>>>>>> it would have been really really nice, if i could have set, for >>>>>>>>>>> the report query, query.SetFetchMode("CarTypes", >>>>>>>>>>> FetchMode.SubSelect) >>>>>>>>>>> or if you will, query.SetBatchSize("CarTypes", 20) >>>>>>>>>>> and same for models >>>>>>>>>>> query.SetFetchMode("CarTypes.Models", FetchMode.SubSelect) or >>>>>>>>>>> query.SetBatchSize("CarTypes.Models", int.MaxValue). >>>>>>>>>>> >>>>>>>>>>> it must be max value because i want all the models, and can't >>>>>>>>>>> possibly know how many car types are going to be there. of course >>>>>>>>>>> it won't >>>>>>>>>>> be alot, because the "query" is going to use paging, but i don't >>>>>>>>>>> really know >>>>>>>>>>> if its 20, 40, or something else. >>>>>>>>>>> >>>>>>>>>>> batch size, currently makes me choose between the use cases, >>>>>>>>>>> slowing down one of them, or makes me query and connect the >>>>>>>>>>> associations my >>>>>>>>>>> self. same goes for sub select, which also issues an inefficient >>>>>>>>>>> query for >>>>>>>>>>> CarTypes and a killer query for the Models >>>>>>>>>>> before my fix it would have been: >>>>>>>>>>> select ... >>>>>>>>>>> from Models m >>>>>>>>>>> where m.CarTypeId in >>>>>>>>>>> (select c.Id >>>>>>>>>>> from CarTypes c >>>>>>>>>>> where c.CompanyId in >>>>>>>>>>> (select company.Id >>>>>>>>>>> from Companies company >>>>>>>>>>> where <could be some crazy crteria - this is the >>>>>>>>>>> same where clause of the very original query>)) >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (i was able to make itthe inefficiency of the query >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Wed, Sep 1, 2010 at 6:58 PM, Fabio Maulo < >>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>> >>>>>>>>>>>> I don't know which is the problem... you said that there is a >>>>>>>>>>>> problem and you want change it using the same tech used by >>>>>>>>>>>> batch-size (using >>>>>>>>>>>> uploaded ids) because subselect seems inefficient in some cases. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On Wed, Sep 1, 2010 at 12:48 PM, nadav s <[email protected]>wrote: >>>>>>>>>>>> >>>>>>>>>>>>> btw, i don't really get what is the problem with subselect, as >>>>>>>>>>>>> it lets you efficiently fetch a whole object graph for the N >>>>>>>>>>>>> fathers that >>>>>>>>>>>>> were fetched in some query, in the most efficient way possible >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On Wed, Sep 1, 2010 at 6:46 PM, nadav s <[email protected]>wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> i don't think its thats low priority, because it is actually a >>>>>>>>>>>>>> thing people expect to happen when they set a fetch mode to >>>>>>>>>>>>>> Eager, at least >>>>>>>>>>>>>> i've seen alot of situations when people really thought that >>>>>>>>>>>>>> thats whats >>>>>>>>>>>>>> going to happen (later finding out it killed their query with >>>>>>>>>>>>>> CP) >>>>>>>>>>>>>> >>>>>>>>>>>>>> about when it is helpful - exactly in the situations diego >>>>>>>>>>>>>> described. two use cases, >>>>>>>>>>>>>> in one of them you query the fathers and gonna need only one >>>>>>>>>>>>>> of the father's collection, and for the other >>>>>>>>>>>>>> you're gonna need all of their collections. >>>>>>>>>>>>>> it gets more complicated when there are grandchildren >>>>>>>>>>>>>> involved, and in one of the situations you want the grand >>>>>>>>>>>>>> children of one of >>>>>>>>>>>>>> the childs, and in the other situation, because you load an >>>>>>>>>>>>>> object graph, >>>>>>>>>>>>>> you're gonna need all of them. >>>>>>>>>>>>>> >>>>>>>>>>>>>> now, either you implement (similar to what diego said) the >>>>>>>>>>>>>> loading of the collections yourself, or you gonna have to live >>>>>>>>>>>>>> with the >>>>>>>>>>>>>> batch size slowing down the first situation, where you would >>>>>>>>>>>>>> have prefered >>>>>>>>>>>>>> lazy loading without batching >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On Wed, Sep 1, 2010 at 5:22 PM, Diego Mijelshon < >>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have entities where batch loading helps in some use cases >>>>>>>>>>>>>>> but it loads lots of unneeded entities/collections in other >>>>>>>>>>>>>>> complex use >>>>>>>>>>>>>>> cases, where I have many proxies but only use a few. >>>>>>>>>>>>>>> My current workaround is doing "manual batch loading" (i.e. >>>>>>>>>>>>>>> dummy query) in the cases where I need it. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be definitely a low-priority but nice-to-have >>>>>>>>>>>>>>> feature. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Diego >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wed, Sep 1, 2010 at 10:12, Fabio Maulo < >>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It is possible for batcher (INSERT, UPDATE,DELETE). >>>>>>>>>>>>>>>> I don't understand where it is useful for >>>>>>>>>>>>>>>> collection/relations batch-size. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On Wed, Sep 1, 2010 at 9:37 AM, Diego Mijelshon < >>>>>>>>>>>>>>>> [email protected]> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Being able to override batch-size would be useful. >>>>>>>>>>>>>>>>> Implementing it requires messing with more than one part of >>>>>>>>>>>>>>>>> the >>>>>>>>>>>>>>>>> infrastructure, though. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Diego >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Fabio Maulo >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Fabio Maulo >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Fabio Maulo >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> >> >> -- >> Fabio Maulo >> >> >
