What does Future() means in NHibernate?

Question

I'm new to NHibernate the description for IEnumerable Future(); says the following

// Summary:
//     Get a enumerable that when enumerated will execute a batch of queries in
//     a single database roundtrip

Just wondering what does it means, the description has nothing to do with the word 'future'

Answer 1

Future allows to execute two or more sql in a single roundtrip, as long as the database supports it.

It's also almost transparent, so you'll want to use Futures whenever possible. If NHibernate can't execute the queries in a single roundtrip, it will execute the queries in two or more, as expected.

From http://ayende.com/blog/3979/nhibernate-futures

Let us take a look at the following piece of code:

using (var s = sf.OpenSession())
using (var tx = s.BeginTransaction())
{
    var blogs = s.CreateCriteria<Blog>()
        .SetMaxResults(30)
        .List<Blog>();
    var countOfBlogs = s.CreateCriteria<Blog>()
        .SetProjection(Projections.Count(Projections.Id()))
        .UniqueResult<int>();

    Console.WriteLine("Number of blogs: {0}", countOfBlogs);
    foreach (var blog in blogs)
    {
        Console.WriteLine(blog.Title);
    }

    tx.Commit();
}

This code would generate two queries to the database Two queries to the database is a expensive, we can see that it took us 114ms to get the data from the database. We can do better than that, let us tell NHibernate that it is free to do the optimization in any way that it likes

using (var s = sf.OpenSession())
using (var tx = s.BeginTransaction())
{
    var blogs = s.CreateCriteria<Blog>()
        .SetMaxResults(30)
        .Future<Blog>();
    var countOfBlogs = s.CreateCriteria<Blog>()
        .SetProjection(Projections.Count(Projections.Id()))
        .FutureValue<int>();

    Console.WriteLine("Number of blogs: {0}", countOfBlogs.Value);
    foreach (var blog in blogs)
    {
        Console.WriteLine(blog.Title);
    }

    tx.Commit();
}

Instead of going to the database twice, we only go once, with both queries at once. The speed difference is quite dramatic, 80 ms instead of 114 ms, so we saved about 30% of the total data access time and a total of 34 ms.