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 > >
