can you help me with the question i've asked?
does this seem ok? - the exception that i throw, i'm completely not sure
about this
public void SetFetchingBatchSize<TEntity>(Expression<Func<TEntity,
IEnumerable>> 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);
}
about the static constraint, i think ienumerable is a fair choice as it
covers all association, and who ever set a batch size on a string property,
its kinda his fault and he deserves his runtime exception :)
On Fri, Sep 3, 2010 at 2:47 PM, Wenig, Stefan <[email protected]>wrote:
> I don’t see how catching _*some*_ errors statically is „useless”. The
> constraint for non-generic IEnumerable is more expressive too, and costs
> nil.
>
>
>
> *From:* [email protected] [mailto:
> [email protected]] *On Behalf Of *Diego Mijelshon
> *Sent:* Friday, September 03, 2010 1:41 PM
>
> *To:* [email protected]
> *Subject:* Re: [nhibernate-development] implementing FetchMode.SubSelect
> per query, and improving it
>
>
>
> You are right.
>
> Since the validation is useless, you can just use Func<T, object>, like
> ConfORM
>
> Diego
>
> On Fri, Sep 3, 2010 at 08:04, 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
> >
> >
> >
> >
> >
> >
> >
>
>
>
