Development has been a long journey. Already back in 2006 we started development for the 2.0 version. In that time most of the work was done by Max Gaerber. He did a fantastic job in the design of the generic handling of content items.

Then somewhere in 2007 we started the new admin with Castle Monorail, did a spike with the first ASP.NET MVC, changed back to Monorail and finally changed to ASP.NET MVC again. The switch from ASP.NET WebForms to MVC for the site admin allowed us to do some pretty advanced AJAX stuff. The result is still a little rough around the edges, but it’s usable for experimental purposes.

Download it at http://sourceforge.net/projects/cuyahoga/files/.

My initial thoughts were ‘why worry, there are plenty alternatives like NHibernate, LLBLGen Pro or LINQ to SQL’ and although I agree with the content of the vote of no confidence, I decided not to sign. That was until realized that as a contractor, you often have to confirm to the technology that the customer has adopted, so it’s to be expected that a lot of future projects have EF as their O/R mapping layer because ‘Microsoft says it’s the way to do data access’. I signed and yes, it’s the selfish me that made me do it.

So now we’re one year later and I just started on a new contract where EF is being used and as I already feared one year ago things are not pretty. The previous developers seem to have struggled a lot, which resulted in poor performance and lots of workarounds.

And you know what: I don’t blame EF itself or the developers but only Microsoft marketing for labeling the Entity Framework as the ‘preferred magic way to do data access’ and all the surrounding blah of future products that will build on EF so people blindly take it as their weapon of choice.

Sorry for this somewhat negative post, but I had to write this off.

Well, I can finally say that Cuyahoga 2.0 will work under medium trust!

Castle DynamicProxy

Last week, someone mentioned on the Castle users list that DynamicProxy was supposed to work under medium trust and this immediately triggered me. DynamicProxy had always been the key part that prevented Cuyahoga, NHibernate, and lots of other software from running under medium trust because it generates assemblies on the fly and that’s not allowed (at least pre-NET 2.0 SP1).

So, I checked out a fresh version of the Castle trunk, built it with AllowPartiallyTrustedCallers and copied the assemblies to Cuyahoga that was set to run under medium trust.
Unfortunately, still no luck. The dreaded SecurityException showed its yellow screen, but instead of giving up immediately, I took a deep breath and started digging the DynamicProxy sources. The solution was a simple one: DynamicProxy calls AssemblyBuilder.DefineDynamicModule and used the overload that generates debug symbols. Changing that to not generate the debug symbols anymore made it work under medium trust! I send a patch to the Castle guys and lets hope it can be incorporated. This allows NHibernate to run under medium trust without turning off lazy-load on class mappings or using a special proxy generator.

One caveat: the Castle trunk requires .NET 3.5, so we can’t fix it for the 1.6.x branch of Cuyahoga which is .NET 2.0.

Lucene.Net

Second, Lucene.Net didn’t work under medium trust and boy, that was easy to fix: a single call was made to a relative file path, which is not allowed. Changed that to use the full path and it worked. Submitted a patch and I hope they will accept it.

Cuyahoga

So, with the libraries working under medium trust, I was ready to roll, at least I thought so. It appeared however that Cuyahoga also did some nasty things that are not allowed under medium trust, such as requesting a HttpModule instance from the appdomain and some file access outside the application root. Fortunately these were easy fixes and now I have everything working just fine under medium trust.

I think, I’ll leave medium trust turned on in the development version to signal issues in an early state.

User has a many-many association with Role and Role has a many-many association with Site. I simply wanted all users that belong to a given site (and a whole slew of other optional parameters, therefore the Criteria query).

With hql this is simple:

select distinct u from User u join u.Roles r join r.Sites s where s.Id = :siteId

With a criteria query, it appeared a little bit harder. First I tried this:

ICriteria crit = session.CreateCriteria(typeof(User))

    .CreateCriteria("Roles") // traverse into Roles

        .CreateCriteria("Sites") // traverse into Sites

            .Add(Expression.Eq("Id", siteId);

Note the absence of the distinct keyword anywhere in the query. A nice Cartesian Product was the result due to the joins on the linking tables. Some googling showed that we can get distinct results with Criteria queries by applying the DistinctRootEntityResultTransformer via Criteria.SetResultTransformer() but that all happens in memory and not in the database query (call me old-fashioned, but I’d like my database results properly filtered ).

Finally, I found the solution in using subqueries:

ICriteria crit = session.CreateCriteria(typeof(User));

DetachedCriteria roleIdsForSite = DetachedCriteria.For(typeof (Role))

    .SetProjection(Projections.Property("Id"))

    .CreateCriteria("Sites", "site")

    .Add(Expression.Eq("site.Id", siteId.Value));

DetachedCriteria userIdsForRoles = DetachedCriteria.For(typeof(User))

    .SetProjection(Projections.Distinct(Projections.Property("Id")))

    .CreateCriteria("Roles")

        .Add(Subqueries.PropertyIn("Id", roleIdsForSite));

crit.Add(Subqueries.PropertyIn("Id", userIdsForRoles));

Yes, that’s an insane amount of code to do something that simple, but it works and the generated SQL is highly efficient . Notice the distinct projection in the second DetachedCriteria (userIdsForRoles).

I’d really appreciate it if somebody has any suggestions for improvement.