Another question about this feature. How should we behave with regard to caching? I am of the opinion that if _all_ the future queries are cachable, we should set the multi query to be cachable. The idea is that it is probably faster to go to the DB than try to split hairs with the query. thoughts?
On Mon, Apr 13, 2009 at 8:24 PM, Davy Brion <[email protected]> wrote: > both Future<T> and FutureValue<T> now fall back to non-batching behavior if > the current Driver doesn't support query batching > > > On Tue, Apr 7, 2009 at 5:57 PM, Fabio Maulo <[email protected]> wrote: > >> In the other mail ?yes, but you can study it more deeper during >> development and if you find something else... well... you sure know. >> >> 2009/4/7 Davy Brion <[email protected]> >> >>> sure >>> >>> >>> do you think the approach i outlined in the other thread would be >>> sufficient? >>> >>> >>> On Tue, Apr 7, 2009 at 5:51 PM, Fabio Maulo <[email protected]>wrote: >>> >>>> Davy, do you want work on it ? >>>> >>>> 2009/4/7 Fabio Maulo <[email protected]> >>>> >>>> 2009/4/7 Ayende Rahien <[email protected]> >>>>> >>>>>> 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. >>>>>> >>>>> >>>>> I worry about multi-RDBMS support and about all other IQuery/ICriteria >>>>> feature support as UniqueResult, ResultTrasformer and so on. >>>>> >>>>> -- >>>>> Fabio Maulo >>>>> >>>> >>>> >>>> >>>> -- >>>> Fabio Maulo >>>> >>> >>> >> >> >> -- >> Fabio Maulo >> > >
