i'd think so too, unless i'm missing something On Tue, Apr 7, 2009 at 4:33 PM, Fabio Maulo <[email protected]> wrote:
> 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 >
