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 > > > > On Wed, Sep 1, 2010 at 09:23, nadav s <[email protected]> wrote: > >> ok i get your point. >> but: >> 1. It can be overriden with eager loading, but not with regular lazy >> loading >> so if you have two use cases, one that loads all fathers and accesses one >> or two of their children, and another that want to batch load the children. >> setting batch size in the mappings don't give full control over batching >> because it can't be changed for a specific query. >> >> do you think it will be a nice feature to enable overriding the batch size >> for a sepecific query, with lazy fetching, and also >> having lazy fetching as default and enabling, per query, set the batch >> size for a collection and a collection's collection? >> >> if not, i'll let it go, i just know we had some issues with selecting a >> whole graph, but not all the time, and subselect was impossible to use, and >> batch size gave good but not optimistic performance because it isn't >> overidable with fetch lazy and vise versa >> >> On Wed, Sep 1, 2010 at 3:11 PM, Fabio Maulo <[email protected]> wrote: >> >>> 1. It is wrote in the mapping but you can eager fetch a collection in a >>> specific query >>> 2. as you saw "subselect" has a different behavior, for that reason >>> batch-size is needed >>> 3. I can't understand the sense of your question. batch-size=500 will >>> upload at most 500 collections but if the session has only 25 owner it will >>> load 25 collections. If in the session you have 900 owners, NH will load 500 >>> collections first then when you will try to access to the collection of >>> owner 501, and only if you will try it, NH will load the next batch of 400 >>> collections. (Note: if you have 900 collection-owner in the session, your >>> problem is not the performance). >>> >>> subselect may cause more problems than it solves (you know it). >>> In my strictly personal opinion, subselect should be removed (as should >>> be removed composite-id and its friends). >>> >>> >>> On Wed, Sep 1, 2010 at 8:52 AM, nadav s <[email protected]> wrote: >>> >>>> thanks for the response fabio. >>>> few questions: >>>> >>>> 1. as far as i can see this is also something that is set via mappings >>>> and cannot be set/overriden for a specific query >>>> 2. if this is batch size what's the fetch="subselect" for? >>>> 3. it might be impossible to know the required batch size, if the query >>>> isn't paged but just filtered with some filter on the entity, and the >>>> collections should be fetched for the whole results of the first query >>>> >>>> so first of all, i think the improvement of the fetch="subselect" is >>>> good for performance in any case don't you think? >>>> should i try to focus on enabling batch-size to be set for a specific >>>> query instead of focusing on sub select being set for a specific query? do >>>> you agree that it could be a nice feature? >>>> >>>> thanks. >>>> >>>> On Wed, Sep 1, 2010 at 1:39 AM, Fabio Maulo <[email protected]>wrote: >>>> >>>>> what you are looking for is not subselect but batch-size. >>>>> The batch-size will use IDs of collection-owner loaded in the session. >>>>> >>>>> >>>>> On Tue, Aug 31, 2010 at 4:32 PM, nadav s <[email protected]> wrote: >>>>> >>>>>> hello, following the jira i've opened that explains the new feature: >>>>>> *NH-2316 <http://216.121.112.228/browse/NH-2316>* >>>>>> i've started working on it to hopefully upload a patch in the near >>>>>> future. >>>>>> >>>>>> few issues with the current implementation of subselect fetching: >>>>>> >>>>>> 1. Its available only in the mappings, and not per criteria\hql >>>>>> query\linq query\query over >>>>>> >>>>>> 2. It isn't overrideable with fetch mode lazy. the reason is that it >>>>>> is not set for a specific query, but the persister of the collection, >>>>>> which >>>>>> is set as fetch="subselect", is some special persister for sub select >>>>>> fetched collections. >>>>>> >>>>>> 3. the query that is issued because of the subselect is very >>>>>> in-efficient. if the first query is: >>>>>> >>>>>> from Foo f >>>>>> where f.Country.Region.Name = 'CoolRegion' >>>>>> >>>>>> then the sub query created for foo.Children will be: >>>>>> >>>>>> from Child c >>>>>> where c.Foo.Id in >>>>>> (select f.Id >>>>>> from Foo f >>>>>> where f.Country.Region.Name = 'CoolRegion') >>>>>> >>>>>> >>>>>> notice that if the query on foo has joins\sub selects then the query >>>>>> that gets foo's children is very inefficient, because after the query on >>>>>> foo >>>>>> was executed >>>>>> the ids of foo are available so the query could easily be >>>>>> >>>>>> from Child c >>>>>> where c.Foo.Id in (?,?,?...? >>>>>> where the ? are the ids of the foos. >>>>>> >>>>>> the 1 and 2 issues, make the subselect fetch unusuable when there are >>>>>> 2 use cases, one where lazy is appropriate and one where subselect >>>>>> fetching >>>>>> is appropriate >>>>>> first of all, i'll be hapy to get your input about this. >>>>>> >>>>>> fixing issue 3 was suprisingly easy, >>>>>> i've just replaced the code in NHibernate.Engine.SubselectFetch that >>>>>> used to take the query string of the original query to be used for the >>>>>> sub >>>>>> select >>>>>> and replaced it with this code: >>>>>> >>>>>> public SqlString ToSubselectString(string ukname) >>>>>> { >>>>>> SqlStringBuilder sqlBuilder = new SqlStringBuilder(); >>>>>> for (int i = 0; i < this.resultingEntityKeys.Count; i++) >>>>>> { >>>>>> if (i != 0) >>>>>> { >>>>>> sqlBuilder.Add(","); >>>>>> } >>>>>> sqlBuilder.AddParameter(); >>>>>> } >>>>>> SqlString sqlString = sqlBuilder.ToSqlString(); >>>>>> return sqlString; >>>>>> } >>>>>> >>>>>> of course i also had to set the query parameters for the ids. >>>>>> taking the ids of the original query was easy because they are already >>>>>> there (in this.Results) >>>>>> all unit tests pass so i think its ok. >>>>>> >>>>>> about issues 1 and 2 - enabling a FetchMode.SubSelect, and in general, >>>>>> making subselect a fetch mode just like join - i wanna start working on >>>>>> that >>>>>> but first would like to know that you think all of this is a good idea >>>>>> and if you have pointers on how to do it - because >>>>>> for criteria its obvious - just use the FetchMode, for Linq its >>>>>> obvious - there needs to be an extention method but for hql - should it >>>>>> be a >>>>>> methid of IQuery or >>>>>> should it be some token in the HQL? >>>>>> >>>>>> >>>>>> for conclusion, i think that once implemented like that, it will be >>>>>> very very easy to fetch a whole object graph for a paged query on the >>>>>> aggregate root. >>>>>> >>>>>> thanks in advance. >>>>>> Nadav. >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> Fabio Maulo >>>>> >>>>> >>>> >>> >>> >>> -- >>> Fabio Maulo >>> >>> >> > -- Fabio Maulo
