Today I freaked out two co-workers by looking at their code and saying (respectively) "How long have you worked with C?" and "You didn't get a lot of time with C++, right?"

The pieces of code in question were: (for the C comment)

Customer customer = null
for(int i=0;i<array.Length;i++)
{
	customer = new Customer();
	//do stuff
}

And: (for the not a lot of time in C++ comment)

int totalCarCount;
if( IsValid )
{
	totalCarCount = GetValidTotalCars();
}
else
{
	totalCarCount = GetInvalidTotalCars();
}

int totalWheelCount;
DoComplexWheelCalculation( out totalWheelCount);

And yes, the examples here are fake, and both are good developers, and I just said what came to mind first :-)

Coworker:

We see this issue on this use case, is this a bug?

Me:

Well, it works exactly the way we intended it to work, just not as the client expected it to work.

Thanks for all the feedback about this feature, I have implemented it and you can find the code here.  Instead of explaining, I am going to let the test speak for themselves. Consider this a first iteration, and I am now accepting patches for this. :-)

[Test]
public void CanUseCriteriaBatch()
{
    ICollection<SMS> loadedMSGs = null;
    new CriteriaBatch(session)
        .Add(DetachedCriteria.For<SMS>(), Order.Asc("id"))
        .OnRead<SMS>(delegate(ICollection<SMS> msgs) { loadedMSGs = msgs; })
        .Execute();
    Assert.IsNotNull(loadedMSGs);
}

[Test]
public void CanUseCriteriaBatchForUniqueResult()
{
    ICollection<SMS> loadedMSGs = null;
    SMS loadedMsg = null;
    new CriteriaBatch(session)
        .Add(DetachedCriteria.For<SMS>(), Order.Asc("id"))
            .OnRead<SMS>(delegate(ICollection<SMS> msgs) { loadedMSGs = msgs; })
        .Add(DetachedCriteria.For<SMS>())
            .Paging(0, 1)
            .OnRead<SMS>(delegate(SMS msg) { loadedMsg = msg; })
        .Execute();
    Assert.IsNotNull(loadedMSGs);
    Assert.IsNotNull(loadedMsg);
}

[Test]
public void CanUseCriteriaBatchWithAutomaticCountQuery()
{
    ICollection<SMS> loadedMSGs = null;
    int msg_count = 0;
    SMS loadedMsg = null;
    new CriteriaBatch(session)
     .Add(DetachedCriteria.For<SMS>(), Order.Asc("id"))
         .OnRead<SMS>(delegate(ICollection<SMS> msgs, int count) { loadedMSGs = msgs;
                                                                     msg_count = count;})
     .Add(DetachedCriteria.For<SMS>())
         .Paging(0, 1)
          .OnRead<SMS>(delegate(SMS msg) { loadedMsg = msg; })
    .Execute();
    Assert.IsNotNull(loadedMSGs);
    Assert.AreEqual(1, msg_count);
    Assert.IsNotNull(loadedMsg);

}

I was asked how we will approach the same Multi Query approach with Linq integration, here are some thoughts about it.

var posts = from post in data.Posts
            where post.User.Name == "Ayende"
		orderby post.PublishedDate desc;
var postsCount = posts.Count();
posts.Skip(10).Take(15);

new LinqQueryBatch()
 .Add(posts)
 .Add(postsCount)
 .Execute();//perform the query

foreach(Post p in posts)//no query
{
  Console.WriteLine(p.ToString());
}
//no query
Console.WriteLine("Overall posts by Ayende: {0}", postsCount.Single() );

The LinqQueryBatch in this case doesn't need to pass delegates to process the results, it can modify the Linq Query directly, so trying to find the result will find the one that was already loaded when we executed the multi query.

Again, this is something that I am merely thinking about, no concrete code created.

I mentioned that I recently had a shift in my think about having services that return query objects. Now I have more interesting problems. How do I test such a thing? To be more accurate, how do you test such a thing in an accurate & maintainable way? To say that queries can be complicated is an understatement. You can try to deconstruct the query, but is this a really good idea? Something as simple a inner vs. left join can have interesting implications.

I guess that I am asking whatever this approach still allows for a Unit Test.

Right now I am testing that against an in memory database, so it mostly involved setting up the data, calling the service that returns the query, execute that and verify the results.

Any thoughts?

I asked before, but didn't get any conclusive answers, what do you think about this syntax for raising events in Rhino Mocks. I spiked the implementation, and the code blow works. As I said, I don't like the awkward syntax of GetLastEventRaiser(), nor the reliance on EventRaiser.Create(mock, "Load"), because it relies on strings.

Does it make sense? Readable? Maintainable?

[Test]
public void Raise_FromEventRaiser_RaiseTheEvent()
{
    MockRepository mocks = new MockRepository();
    IWithCustomEvents withCustomEvents = mocks.DynamicMock<IWithCustomEvents>();
    mocks.ReplayAll();
    
    bool myEventCalled = false;
    withCustomEvents.MyEvent += delegate { myEventCalled = true; };

    withCustomEvents.MyEvent += EventRaiser.Raise(this, EventArgs.Empty);

    Assert.IsTrue(myEventCalled);
}

I wanted to say that the implementation was simple, but it relies on emitting code at runtime, so is it simple?

Anyway, I am waiting for some additional responses

Sahil Malik points out that Microsoft has found a way to distribute Virtual Machines for Windows by time bombing them. In fact, they now have quite a number of them available for download.

Sahil has another request, to be able to do the same himself:

Extend that time bomb mechanism, so parties other than Microsoft can play. I should be able to create a solution based on MSFT technologies, and hand over a VHD for the world to play.

That is something that I would like to see very much. My company has a lot of virtualization stuff going on, and I would be very interested in being able to legally distribute a VM that can be use to boot-and-go in various scenarios.

I would like to add another request to that, not only do we need to be able to distribute time bombed VMs, we also need a way to white-list them, if we want to use the VM for more than the allowed period. My company has done several projects where deployment has consisted of xcopy the VM file to the VM server, and the booting.

I spoke about it in the past, here

As I have already explained, I am doing a lot of work with NHibernate's MultiCriteria and MutliQuery. There are very powerful, but they are also mean that I am working at a level that has a lot of power, but a bit of a complex syntax. I want to improve that, but I am not sure what the best way to do it. Anything here is blog-code, meaning that I didn't even verified that it has valid syntax. It is just some ideas about how this can go, I am looking for feedback.

The idea here is to have a better way to use NHQG expressions, and to remove the need to manually correlate between the index of the added query and the index in the result set. It should also give you better syntax for queries that return a unique result.

new CriteriaQueryBatch()
 .Add(Where.Post.User.Name == "Ayende", OrderBy.Post.PublishedDate.Desc)
   .Paging(0, 10)
   .OnRead(delegate(ICollection<Post> posts) { PropertyBag["posts"] = posts; })
 .Add(Where.Post.User.Name == "Ayende")
   .Count()
   .OnRead(delegate(int count) { PropertyBag["countOfPosts"] = count; })
 .Execute();

Waiting for you thoughts...

This is from a advertising brochure that my company has distribute, for a virtualization conference that we recently did.

I have included the sponsorships part only, it says "Gold Sponsor: IBM", "Silver Sponsors: VMWare, FilesX".

The problem is that in Hebrew, the word for Silver is the same word for Money.

This has the affect of me reading it as: "Money Sponsors: VMWare, FilesX".

That sounds... crass.

The problem is actually not limited to my company's conferences, but it actually wide spread in Israel. I really wish they would think about a different term.

Here is an interesting topic. My ideal data access pattern means that there is a single query per controller per request (a request may involve several controllers, though). That is for reading data, obviously, for writing, I will batch the calls if needed. I am making heavy use of the Multi Criteria/Query in order to make this happen.

I have run into a snug with this approach, however. The problem is that some of the services also do data access*. So I may call to the authorization service to supply me with the current user and its customer, and the service will call the DB to find out about this information. I would rather that it would not do that, since that means extra round trips. Now, NHibernate has the idea of a DetachedCriteria, a query that has semi independent life, can be constructed at will and massaged to the right shape anywhere in the code.

Now, I have the following options. Use the normal method:

ICollection<Customer> customers = AuthorizationService.GetAssociatedCustomers();
ICollection<Policy> policies = Repository<Policy>.FindAll(
	Where.Policy.Customer.In(customers)
  );

PropertyBag["customers"] = customers;
PropertyBag["policies"] = policies;

Use DetachedCriteria as a first level building block:

DetachedCriteria customersCriteria = AuthorizationService.GetAssociatedCustomersQuery();
IList results = session.CreateMultiCriteria()
	.Add(customersCriteria)
	.Add(DetachedCriteria.For<Policy>()
		.Add( Subqueries.PropertyIn("id", CriteriaTransformer.Clone(customersCriteria)
                                                    .SetProjection(Projections.Id())
                      ) )
	).List();

ICollection<Customer> customers = Collection.ToArray<Customer>(results[0]);
ICollection<Policy> policies = Collection.ToArray<Policy>(results[1]);
PropertyBag["customers"] = customers;
PropertyBag["policies"] = policies;

Remember, I consider Querying a Business Concern, so I like the ability to move the query itself around.

Thoughts?

*  By data access, I mean, they call something that eventually resolves in a DB call.