Future queries not executed if no support for multiple queries

[StormimOn]

NHibernate 5.X did change a little the Future extensions methods.
This cause a regression if there is no support for multiple queries, because in some scenarios the future queries won't be called.

For example

var query = Session.QueryOver<ParentObject>()....Future<ParentObject>();
Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollection1)....Future<ParentObject>();
Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollection2)....Future<ParentObject>();
...
Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollectionN)....Future<ParentObject>();

var result = query.SingleOrDefault();

In this case the queries fetching childs collections won't be called.
With NH 3.X the .Future() would react like a .List() so there was no problem.

[fredericDelaporte]

Well, this is indeed a missing breaking change in release notes. But it has been done on purpose, see here.

This also adjusts a "detail": previous implementation was causing an immediate execution of the query in case of lack of multiple query support, contrary to what does FutureValue. Now it will be delayed too, so a discarded future query will not have its query run at all when multiple queries are not supported, it will be run only if the future query is actually enumerated.

So the code above should be changed to:

var query = Session.QueryOver<ParentObject>()....Future<ParentObject>();
var childQueries = new List<IFutureEnumerable<ParentObject>>();
childQueries.Add(Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollection1)....Future<ParentObject>());
childQueries.Add(Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollection2)....Future<ParentObject>());
...
childQueries.Add(Session.QueryOver<ParentObject>().Fetch(x => x.ChildCollectionN)....Future<ParentObject>());

// Using the IFutureEnumerable directly as an IEnumerable is deprecated.
var result = query.GetEnumerable().SingleOrDefault();

// When Future are actually supported by the data provider, this code will be no-op.
// Otherwise it is mandatory for getting the children futures actually executed.
foreach(var cq in childQueries)
{
    cq.GetEnumerable();
}

By the way I guess this code is not using FutureValue then Value and use Future then SingleOrDefault instead because FutureValue was already working that way, never being immediately executed, and ending up not executed at all in case of lack of Future support.

[StormimOn]

Thanks for the fast answer.
I did try your code, but the children futures are not executed when only calling the .GetEnumerable()
I need to add a call to a method which enumerate the result, like .GetEnumerable().Any()

I also found a solution about making your own driver so you can create cursors (Oracle) to manage multi queries.

[fredericDelaporte]

Indeed, GetEnumerable is implemented as an iterator, which causes it to be no-op until the iteration starts actually... This is a bug, it contradicts its purpose.

I also found a solution about making your own driver so you can create cursors (Oracle) to manage multi queries.

This sounds even better for your case. If the implementation works well, it could be contributed into NHibernate Oracle drivers.

[StormimOn]

This is the solution I did try and it works well in my case.

https://stackoverflow.com/questions/10046461/nhibernate-multi-query-futures-with-oracle/35210290#35210290

[fredericDelaporte]

So, as of 5.0.x and 5.1.x, this is a known behavior, closing this issue. Nonetheless, for 5.2.0, I propose some refactoring in #1666 which will remove this discrepancy in Future behavior between data providers supporting multi-queries and those not supporting them.