changed the object to ienumerable, still wondring about the argument exception there, weather this is correct
On Fri, Sep 3, 2010 at 1:47 PM, nadav s <[email protected]> wrote: > done but i'm not sure i did it correctly as i never had to proccess a linq > expression... > > is this right? > > public void SetFetchingBatchSize<TEntity>(Expression<Func<TEntity, > object>> association, int batchSize) > { > if (!(association is LambdaExpression) || !(association.Body is > MemberExpression)) > { > throw new ArgumentException("Batch size can only be set by > a lambda expression which returns a member association"); > } > > > > this.SetFetchingBatchSize<TEntity>(ExpressionProcessor.FindMemberExpression(association.Body), > batchSize); > } > > > On Fri, Sep 3, 2010 at 5:44 AM, Diego Mijelshon <[email protected]>wrote: > >> Nice job! >> >> How about a strongly-typed version of the collection ones? >> >> void SetFetchingBatchSize<TEntity>(Expression<Func<TEntity, >> IEnumerable>> association, int batchSize); >> >> Allowing: >> >> session.SetFetchingBatchSize<Father>(f => f.Children, 5); >> >> Diego >> >> >> >> On Thu, Sep 2, 2010 at 20:17, nadav s <[email protected]> wrote: >> >>> *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 >>>>> >>>>> >>>> >>> >> >
