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