fine by me as i always use generic collections, but isn't it possible to map an association with non generic collection? btw, won't it be a problem with a map? IDictionary<int,Child> is not IEnumerable<Child>
On Fri, Sep 3, 2010 at 2:25 PM, Wenig, Stefan <[email protected]>wrote: > Right. Still, if you like to nail stuff down statically, you could do > this: > > > > public void SetFetchingBatchSize<TEntity, > TTargetEntity>(Expression<Func<TEntity, IEnumerable<TTargetEntity>>> > association, int batchSize) > > where TEntity: class, TTargetEntity: class > > > > *From:* [email protected] [mailto: > [email protected]] *On Behalf Of *nadav s > *Sent:* Friday, September 03, 2010 1:07 PM > *To:* [email protected] > *Subject:* Re: [nhibernate-development] implementing FetchMode.SubSelect > per query, and improving it > > > > well an exception will be thrown because a collection persister for company > name won't be found > > > > On Fri, Sep 3, 2010 at 2:04 PM, Frans Bouma <[email protected]> wrote: > > Beware of IEnumerable: 'string' also implements IEnumerable, so > c=>c.CompanyName will also match, while it's not a collection ;) > > FB > > > > 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 > > > > > > > > > > > > > > > > >
