Something to think about

Let's not have any misunderstandings:  I think this is quite ingenious.  It taught me about something that I didn't know could be done.  I intend to study it and learn how it works.

However, I also think it's the least maintainable solution to a simple SQL problem that I have ever seen. 

First Monday of Daylight Savings Time, 2010

My colleague Lydia calls today, "National Be-An-Hour-Late-To-Work Day".

A challenge for you LINQ experts

Imagine a simple, recursive parent-child relationship, modeled in data.  The class definition would be:

class Relationship
{
   public int ChildId { get; set; }
   public int ParentId { get; set; }
}

You have a collection of these things.  Let's define it as an IEnumerable and call it c.

The challenge:
1.  Can you, with one LINQ query, find all the elements that are descendents of a given parent?
2.  (Bonus points) Can you, with one LINQ query, find all "loops" in the collection, where an element is ultimately descended from itself?

How could this be done -- efficiently -- in .Net?

As you can tell if you check out the links on the right, I had a previous career as an IBM AS/400 specialist.  Now, I have a whole rant on the subject of What I Miss About The Bad Old Days, that goes into things the AS/400 did right, but this post is about one thing in particular:  level checks.

A program written on the AS/400, when compiled, contained information about the database tables it had been compiled against.  Specifically, for each table or view (we called them different things, but that's what they were), it contained a guid-like string that represented the structure and some of the attributes of the table / view as it had been at compile time.  If you attempted to run the program against a different table, or the same table after structure changes, the level ids wouldn't match, and the program wouldn't run.  This was called a level check. 

I'd like to be able to do something similar with a .Net application and the database it was written for.  Specifically, I'd like for an application to be able to tell that the stored procedure it's about to call isn't the same procedure that it was compiled for.  Oh, the specifics of the change may or may not matter:  what I want is to have some flag raised that says:  something has changed since we finalized this release.

This would be handy in sorting out problems with installation packages and incorrect deployments.  I'll readily admit that if you had to contend with this during development, it would drive you crazy.   But once you think you have everything finalized, if you could turn on this integrity check, it would be very handy.