I really like the fact that you get rid of the explicit indexing.

Well, I have to say...the syntax you have proposed is actually quite to my liking :)

I have just written a way too long blog post (as usual) that has some relevance to multi querying.

http://www.matshelander.com/wordpress/?p=50

If anyone with experience in this type of thing could tell me why my thinking is wrong it would be hugely appreciated, since this is something I have been struggling with for years...

/Mats

pretty cool syntax, but it would be even cooler if you could do it like this:

ICollection<Post> posts;

int count;

new CriteriaQueryBatch()

.Add(Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc)

.Paging(0, 10)

.StoreIn(ref posts)

.Add(Where.Post.User.Name == "Ayende")

.Count()

.StoreIn(ref count)

.Execute();

not sure if it's actually possible though

@ Ayende,

Pulling the meat from my blog post...do you know if NHibernate suffers from the same problem, that if I do:

Select * From Customer Where Id = 42;

Select * From Order Where Customer.Id = 42;

Select * From OrderLine Where Order.Customer.Id = 42;

(I'm using NPath syntax since I'm not familiar enough with HQL, but I'm hoping you'll see what the statements mean)

...then this will not prevent lazy loading to occur when I access the customer.Orders property and the order.OrderLines properties?

In NPersist, the order.Customer and orderLine.Order properties will be loaded after running these three queries, but the customer.Orders property and the order.OrderLines properties will not be.

Is that the same in NHibernate?

/Mats

+1 anything that makes it easier to use is always awesome. -d

This looks cool! I think the paging and count queries are common enough however that they deserve their own methods:

new CriteriaQueryBatch()

.FindPage( 0, 10, Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc )

    .OnRead( delegate(ICollection<Post> posts, int count)

    {

        PropertyBag["posts"] = posts;

        PropertyBag["countOfPosts"] = count;

    })

.Find( Where.User.IsOnline == true, OrderBy.User.Name )

    .OnRead( delegate(ICollection<User> users) { PropertyBag["onlineUsers"] = users; } )

.Execute();

This way you only have to specify the critieria once!

Bobby

Great ideea. I would really like the comination of StoreInto and FindPage, so

.SelectPaged(0, 10, Where....).Into( ref ICollection<Post>, ref int)

.Select(Where...).Into(ref ICollection<Post>);

IMO the ideea of a query is to get a value not to execute some function with the results.

Imagine if I need to write a try/catch in that anonymous method or even if I need to use the results in order to make another such query :). I would have to use some local variables that will be set from within the anounymous function call.

For me a similar approach hurt more when I needed to do smth like this:

class Foo {

bool TryToGet(ref ICollection results)

{

 someObject.Callmethod( delegate () { results = null; });

}

}

This will not work because ref or out parameters cannot be used inside anounymous function. So here goes the alternative:

class Foo {

bool TryToGet(ref ICollection results)

{

 ICollection buffer = null; // initialize or get error of un-initialized access

 someObject.Callmethod( delegate () { buffer = null; });

 result = buffer;

}

}

... and this is not very nice

Yes, the FindPage would create two queries under the hood. What do you think of this syntax, for C# 3.0:

new CriteriaQueryBatch()

.FindPage<Post>( 0, 10,

    (posts, count) => { PropertyBag["posts"] = posts; PropertyBag["countOfPosts"] = count; },

    Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc )

.Execute();

and for C# 2.0 would be:

new CriteriaQueryBatch()

.FindPage( 0, 10,

    delegate(ICollection<Post> posts, int count) { PropertyBag["posts"] = posts; PropertyBag["countOfPosts"] = count; },

    Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc )

.Execute();

so the developer doesn't forget to include the OnRead callback?

One drawback, however, is that you would need to have several FindPage overloads instead of the OnRead overloads to accept the different delegates.

Thanks,

Bobby

Keeping it flexible with a few shorter signature methods seems like a better idea to me.

new CriteriaQueryBatch()

.Add( Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc )

.Paged(0, 10)

.OnRead(delegate(ICollection<Post> posts, int count) { PropertyBag["posts"] = posts; PropertyBag["countOfPosts"] = count; })

.Execute();

Where the call to Paged(int, int) would know to create the count query under the hood. Like people have said above.

I also think there might be something interesting that could be done with changing the type of the CriteriaQueryBatch as you build it.

ICollection<Post> posts;

int postCount;

new CriteriaQueryBatch()

.Add( Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc ) // returns a CriteriaQueryBatch<Post>

.Paged(0, 10) // returns a CriteriaQueryBatch<Post, int>

.ExecuteInto(out posts, out postCount);

This would kinda be a bit of a pain to maintain and I am not sure it is worth the slightly cleaner syntax.

I also think that there should be some way of explicitly storing the results in a IDictionary<String, object>.

something like :

new CriteriaQueryBatch()

// ... build it

.ExecuteInto(PropertyBag, "posts", "postCount");

The StoreInto() syntax won't work but there's no reason you couldn't attach a storage slot to a criteria to form a query. I like this better anyways as I wouldn't really want to see 20 queries all being attached in a single statement. It would make documentation a real pain (where to put comments or intermediate variables?).

IQuery<Post> postQuery = new Query(Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc)

.Paging(0, 10)

.OnRead(delegate(ICollection<Post> posts) { PropertyBag["posts"] = posts; }));

IQuery<int> countQuery = new Query(Where.Post.User.Name == "Ayende")

.Count()

.OnRead(delegate(int count) { PropertyBag["countOfPosts"] = count; }));

MultiQuery.Execute(postQuery, countQuery);

PropertyBag["posts"] = postQuery.Result;

PropertyBag["postsCount"] = countQuery.Result;

Argh... my example should have omitted the OnRead callback. Posted too soon. Sorry!

@Ayende

It'll depend a lot on what you intend to do with the results. I don't mind assigning each query to its own variable. It'll be the same number of statements as if I individually Add() them to a CriteriaQueryBatch. It'll be one less anonymous delegate if I just want to assign the results to a variable anyways.

In your case the delegate makes a lot of sense because you're just shoving the results into your Controller's PropertyBag without any further interpretation going on. It'll get messy if you need to take the results of two queries and combine them in some way.

I do like how the delegate allows you to decouple consumption of the query results from the place where the query is eventually executed. That can be quite useful... :-)

I'm curious whether LINQ syntax can be embedded nicely into a MultiCriteria-type query. Seems tricky... How would you gather all of the queries in a batch so that they are evaluated all at once instead of lazily as each the resulting IEnumerable<T> eventually gets traversed?

You know, this reminds me of non-blocking I/O patterns involving the Unix select() function call. Or, at the extreme of some things that are done using continuation passing style to centralize an event loop or some other dispatcher-type mechanism.

Here we've got services that are returning query objects to be batch-evaluated. It's presumes that the services might carry on and do other things with the results when they become available. Bit of a pain to work with but it can cut down on latency.

An equally good approach would be to parallelize the queries. Perform processing in multiple worker threads where possible. Given relatively low contention in the thread pool and Db connection pool, the total latency will be reduced even more than is possible with a batch query.

Not quite good enough. What if your service wants to return some final result? A better approach would be to follow the async token pattern more closely.

public interface IAuthorizationManager

{

IQueryContinuation BeginAuthorization(string userName, string password);

bool EndAuthorization(IQueryContinuation token);

}

public interface IQueryContinuation

{

Query Query { get; }

}

But this is rather clunky since the caller needs to manage all of these continuation tokens, etc... This is the same level of awkwardness seen when working with asynchronous methods a lot. Not good. Moreover, batching up queries for execution is just one of the many possible things you might want to batch up.

This approach is also violating the encapsulation of the service because the caller probably shouldn't need to know that there's a bunch of querying going on. There's a difference between a service that returns a prototypical DetachedCriteria for you to mess around with and one whose guts are hanging out.

I'm not sure how badly parallelizing the queries would impact the database. Clearly more connections would be active at a time and more requests would be under way concurrently. Quite likely each request would individually take longer to run so lock contention would become more of a problem. The whole batch is likely to finish sooner though... It'll certainly squeeze the database for bandwidth...

@ Ayende,

Thanks a million!

/Mats