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