I'm with Frans on this. I've been thinking about this myself but I thought of making a Linq version of ISession.CreateFilter. Like:
var foo = session.Get<Foo>(1); session.FilterQuery(foo.Bars).Where(x => x.BarName == "a").List(); Or something... /Johannes On Fri, Sep 3, 2010 at 9:12 AM, Frans Bouma <[email protected]> wrote: > > I think Frans can tell that was just a joke :-) > > I chuckled :) > > > 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); > > ? > > > 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. > > > Other than that, the feature could be handy :) (I haven't tried it > out btw) > > FB > > > > > Diego > > > > > > > > On Fri, Sep 3, 2010 at 00:13, Fabio Maulo <[email protected]> wrote: > > > > > > Take care with your words... > > The fact that I had some squabble with Frans does not mean that I > > don't respect him and does not mean that we have to review all patches > with > > High priority. > > > > NH-2319 is the LINQ version of our CreateFilter, the patch is > > interesting but it need to be analyzed with more details. > > So far any LINQ applied to a collection, retrieved by NH, is always > > safe as any LinqToObject. > > Your request seems a bug masquerade of feature and needs a cautions > > discussion > > > > > > On Thu, Sep 2, 2010 at 11:46 PM, Diego Mijelshon > > <[email protected]> wrote: > > > > > > Anyone? > > > > C'mon guys, at least some criticism from the wind team! > > If you don't look at the received patches, Frans Bouma > wins! > > (just kidding) > > > > Diego > > > > > > > > On Wed, Sep 1, 2010 at 00:19, Diego Mijelshon > > <[email protected]> wrote: > > > > > > I've implemented something I've seen requested > several > > times in SO and the users list: the ability to query persistent > collections > > using LINQ (server side, without initializing the collection and without > > referencing NHibernate). > > > > Patch: http://216.121.112.228/browse/NH-2319 > > > > <http://216.121.112.228/browse/NH-2319> This > > implementation should work for generic bag, set and list, with two > > limitations: the relationship must be one-to-many and bidirectional. This > > should still account for the majority of the collections out there. > > There are probably many other ways in which it can > be > > improved, but I think it will be a useful feature. > > > > I'd really appreciate if any of the committers > takes > > some minutes to review it and, hopefully, include it. Ping me if you have > > any questions. > > > > Diego > > > > > > > > > > > > > > -- > > Fabio Maulo > > > > > > > > >
