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
