Easy! no? ;) 2009/4/7 Davy Brion <[email protected]>
> can't we just ask the current driver if multi query is supported, and if > not, call List<T> inside the Future<T> method? > > to the caller, the only difference would be the implementation type of the > returned IEnumerable<T>, of which no assumptions should be made by the > client anyway > > and for FutureValue<T>, we could just execute the query and return a > FutureValue object with it's Value property set to the returned value of the > query. > > i haven't actually tried this, but i don't really see what the problem > could be. > > Clients know about IFutureValue<T> and IEnumerable<T>... whether they > immediately have a value or not, depending on the capabilities of the > current RDBMS, shouldn't really impact their code. > > > On Tue, Apr 7, 2009 at 4:20 PM, Ayende Rahien <[email protected]> wrote: > >> Future is a strong optimization that we make based on features of the >> RDBMS. >> I think that it make sense to make it portable, but I worry about how you >> do it. >> >> >> On Tue, Apr 7, 2009 at 5:15 PM, Fabio Maulo <[email protected]> wrote: >> >>> 2009/4/7 Ayende Rahien <[email protected]> >>> >>>> would you mind sharing it :-) >>>> >>> >>> In NH2.0.0 the code is portable and multi-RDBMS >>> >>> IEnumerable<Category> pl = session.CreateQuery("from >>> Category").List<Category>(); >>> >>> In NH2.1.0 this code is NOT portable and NOT multi-RDBMS, so far >>> >>> IEnumerable<Category> pl = session.CreateQuery("from >>> Category").Future<Category>(); >>> >>> What should write, the developer, if he want a multi-RDBMS solution ? >>> >>> The 2 lines the developer should write are the same we should write in >>> the nh-core >>> >>> -- >>> Fabio Maulo >>> >> >> > -- Fabio Maulo
