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