> > > And yes, it is similar to CreateFilter, with one BIG difference: a > reference > > to NHibernate is not needed, which means you can safely use it from the > > Domain/Model classes without injecting a reference to the repository. > > > > The envisioned scenario is an extension of what can be currently > > accomplished with lazy="extra". > > For example, if you have a Currency entity with an ExchangeRates > collection > > (which is updated daily, hourly, whatever), you can do something like: > > > > var averageJulyRate = currency.ExchangeRates.AsQueryable() > > .Where(r => r.Date >= new DateTime(2010, > 7, > > 1) && > > r.Date < new DateTime(2010, > 8, > > 1) > > .Average(r => r.Rate); > > instead of: (Didn't remember te method on ISession to get an > IQueryable<T>, so I used .Linq<T>) > var averageJulyRate = session.Linq<ExchangeRate>() > .Where(r=>r.Currency.Id == > currency.Id) > .Where(r => r.Date >= new DateTime(2010, 7, > 1) && > r.Date < new DateTime(2010, 8, > 1) > .Average(r => r.Rate); > > ? >
Exactly. > > > Now, I'm sure there are bugs with the implementation, mostly in the form > of > > unsupported scenarios and naïve assumptions, because I'm still learning > NH > > internals... > > But I'm pretty sure the feature itself is not a bug, but something that's > > been actively requested. > > The downside I see is that it makes a call to the DB where you > might > not expect it. With Linq it's already a struggle for some people (actually > more than you'd expect) to determine just from the query where which code > is > ran: in memory or in the DB. With your feature you can think it's an > in-memory thing, but you actually make a call to the db, which could be a > problem when you receive the entities over a wire in a distributed > scenario. > If you want to run in-memory, you can omit AsQueryable. In fact, I thought of a slight modification: if the collection is already initialized, don't go to the DB. Thoughts? Diego
