.NET

What would NHibernate ICriteria look like in .net 3.5?

Brendan Kowitz — Sun, 17 Aug 2008 05:12:29 GMT

If NHibernate decided to ditch compatibility with plain old .net 2.0 and focus on 3.5 how would the ICriteria interface change? Previously I was throwing around an idea of using a simple lambda expression to resolve the property name. Well, I couldn't help but build on this a little more. The following idea is not supposed to be LINQ, that would be far more complicated and LINQ is essentially its own interface, which is not the point. The point is, if ICriteria was written today in .net 3.5, what could it look like? How could it change?

So just to recap, the original code sample looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

Paul later come back and suggested I try using a slightly different signature so that the "Person" object doesn't need to be instantiated for no reason, this means the we can do this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.For<Person>(p => p.FirstName), "John"));

I like this a lot more. So this is the point where I started playing around and wanted to try and implement a neater way of integrating this to add Criterion. First off I tried implementing ICriteria.Add(Restrictions.Eq()) as an expression which looked like:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq<Person>(p => p.FirstName == "John" ));

That is where I got up to in the previous post. So after this I started implementing some of the other functions found on the 'Restrictions' class such as:

.NotNull()
.IsNotNull()
.Not()
.Between()
.Gt() (Greater than)

Then I realized all of the above functions are able to be figured out using the syntax I already had: 'p.FirstName == "John"', so how about p.FirstName != "John", or p.ID > 0 or p.FirstName != null, you get the idea. This being the case, now there is no need for the Restrictions class at all, nearly everything can be figured out by using Add(). The other problem I wanted to solve was not having to keep passing the generic <Person> class in all the time. So I created a class which wraps ICriteria and keeps track of these few things, so now it looks like:

ICriteria c = session.CreateExpression<Person>()
     .Add(p => p.FirstName == "John")
     .Criteria;

Most of the other functions on the Restrictions class can be added the same way:

ICriteria c = session.CreateExpression<person>()
      .Add(p => p.FirstName == "John") //Restriction.Eq()
      .Add(p => p.LastName != null)    //Restriction.IsNotNull() 
      .Add(p => p.ID > 0 && p.ID < 1000) //Restriction.Between()
      .Criteria;

There are also other more complex things that the ICriteria interface does such as adding Projections and Joins. So how would the old AddAlias() function work? Like this perhaps:

ICriteria c = session.CreateExpression<Person>()
      .Alias<Address>(p => p.Addresses, "addr")
            .Add(a => a.Postcode != null)
            .AddAndReturn(a => a.Address2 == null)
      .Criteria;

Bringing it all together, here's a comparison between the old interface and the expressions version.

Current ICriteria:

ICriteria o = session.CreateCriteria(typeof(Person))
    .Add(Restrictions.Eq("FirstName", "John"))
    .CreateAlias("Addresses", "addr")
        .Add(Restrictions.IsNotNull("addr.Postcode"))
        .Add(Restrictions.IsNull("addr.Address2"))
    .AddOrder(Order.Asc("ID"));

Same query using Expressions:

ICriteria c = session.CreateExpression<Person>()
    .Add(p => p.FirstName == "John")
    .Alias<Address>(p => p.Addresses, "addr")
        .Add(a => a.Postcode != null)
        .AddAndReturn(a => a.Address2 == null)
    .OrderAsc(p => p.ID)
    .Criteria;

In conclusion, this is probably not going to revolutionize the global economy, but on some levels I think it feels a little more intuitive and a little more modern. In other respects, it's probably not much less typing then the original. Also with the up and coming linq provider, is this a waste of time? or does it complement it?

Feel free to have a poke around the source, and corresponding tests

NHibernate Type Safety using Lambda Expressions

Brendan Kowitz — Mon, 21 Jul 2008 21:38:48 GMT

I can't remember if this has been around before, I do vaguely remember seeing something like it.

However, I just wanted to apply a snippet of code I found on Paul's blog the other day to NHibernate. Of course we will definitely have type safety in queries when Linq-to-NHibernate is completed. But surely linq-to-nhibernate is not going to be the _only_ way of writing queries.

Using the original code snippet 'as is' would look something like this:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(Restrictions.Eq(Property.GetFor(() => new Person().FirstName), "John"));

This is ok, but a little long winded, so I implemented another class called RestrictBy which can break down a simple lambda expression. So now I can use:

ICriteria c = session.CreateCriteria(typeof(Person));
c.Add(RestrictBy.Eq(() => new Person().FirstName == "John"));
c.UniqueResult();

This also means you'll get compile time errors for incompatible types such as:

Using the lambda expression we get to evaluate the _actual_ property and that property's type. If you wanted to clean this up some more, its not hard to then go and add some extension methods to ICriteria to produce:

ICriteria c = session.CreateCriteria(typeof(Person));
c.AddEq(() => new Person().FirstName == "John");
c.UniqueResult();

So that's it, a simple example at the moment, but it might be an option to look into a little more because the ICriteria interface is still NHibernate's native querying interface and still provides a lot of power, flexibility and programmatic building of queries.

Sourcecode:

RestrictBy.cs also a couple of unit tests here
Paul's Property.GetFor()

EDIT: For further reading, see the follow up post.

NHibernate Compatible Shared Hosts

Brendan Kowitz — Fri, 28 Mar 2008 13:21:04 GMT

NHibernate is a remarkable ORM, however with all the magic comes a few caveats, these being the difficulties running NHibernate apps in a shared hosting environment. I'm still convinced that it's entirely possible, so I've decided to start compiling a list of success and failures that others (and myself) have had in getting things working.

Compatible Shared Hosts

Host Name	Comment	Reference
Webhost4life	Reportedly works with "no hacks"	[ref]
DiscountAsp	I think this should work with IIS7 / Win 2008	[ref]
XHostSolutions	Simply email support and ask to have your application run as Full Trust	This is the host I use.

Shared Hosts known not to work

Host Name	Comment	Reference
Godaddy		[ref]
Crystaltech		[ref]

Untested / Unknown

Host Name	Comment	Reference
DiscountAsp

Useful References / Alternate Ideas

Lazy Loading with nHibernate Under Medium Trust

IDataErrorInfo for ASP.NET

Brendan Kowitz — Thu, 08 Nov 2007 13:42:42 GMT

As far as I'm aware ASP.NET doesn't support IDataErrorInfo, I've asked about this in many places, including Tech.Ed '07 with no success. The closest things I've seen in terms of Business Object level validation is from Enterprise Library validation block (which is attribute based and can render out with custom EntLib web controls) and another example in the Futures Dynamic Data Controls using Linq (I have no idea how this magic validation magically appears).

It all just seems overly complicated, so, have a look at the IDataErrorInfo interface the methods are:

string this [ string columnName ] { get; }
string Error { get; }

Simple and generic. I've been playing around with an idea about how to get this into a generic web control, introducing:

WebValidationControlExtender

Here is an example of the control in design mode:

Here is an example of the control in action using an ObjectDataSource and a plain old DetailsView:

Here's what's going on under the hood.

All you need to do is tell WebValidationControlExtender what ObjectDataSource to hook in to.
When the page is executing and the user tries to insert a record, the DetailsView control builds up an object and sends it into the ObjectDataSource.
WebValidationControlExtender is already listening for Insert and Update events, all it does is check if the object being passed through implements IDataErrorInfo.
If it does, WebValidationControlExtender interrogates the object's columns/properties for errors.
If errors are found, it adds CustomValidators back to the page then goes searching for controls that are using that object datasource (in this case the DetailsView).
When it finds the details view it searches for BoundFields that are bound to the properties with the error, then inserts the red * like in the picture above.

The point is, you could go an implement whatever validation library suites your needs, as long as the object implements IDataErrorInfo the validation works. I just don't understand why ASP.NET doesn't already use something like this, there are so many complicated implementations for validation, I hope this brings some fresh light.

Another SubText Blog

Brendan Kowitz — Sat, 09 Jun 2007 11:14:22 GMT

Yes, I'm one of the crowd now, all because my old host Jumba is turning off the last of their Windows boxes, and coincidentally, the one I was hosted on. This has happened previously when they shut down some legacy Windows servers and forced everyone on it to upgrade.

Since Jumba is now no longer offering HELM windows hosting they have recommended xHostSolutions who have pretty comparative deals to what I was previously on, only better. This now gives me access to an MS Sql Server database, so I thought I'd take the opportunity to install SubText.

I still think that Single User Blog is a great place to start when you want to start sinking your teeth into ASP.NET 2.0, its very easy to get your head around and start using all the cool features that ASP.NET has to offer. This is one thing, but I'm now itching to try something a little more feature rich such as SubText. I do admire what wordpress has achieved in the blogging world, but I just can't seem to stray away from .NET, and not to mention the fact that wordpress is written in PHP.

ERROR: 42601: a column definition list is only allowed for functions returning record

Thu, 15 Mar 2007 11:30:35 GMT

Since the postgres forums appear to be a little quite, I'll post my error here as well.

This error is in regards to the postgres .net npgsql driver and seemed to only occur when using stored procs.

The Error
The behavior I experienced happens when using stored procedures started out with me getting the following error:
ERROR: 42601: a column definition list is only allowed for functions returning "record"

After checking and double checking the stored proc and the parameters I was sending in I turned Npgsql's debugging on. The error appears to be coming from a statement that looks like the following:
select * from sitemenus_ins(68::int4,34::int4) as (psitemenuid int4, prowstamp timestamp )
This line of sql fails.

However the following will work:
select * from sitemenus_ins(68::int4,34::int4)
The only difference being that the second one has the 'as(...' clause taken off.

Strange Observation:
The snippet in question is executed automatically by the provider after the NpgsqlCommand.cs class does some other queries to try and match the list of the parameters that are in the stored procedure it is about to execute. However, the 'select' it uses to determine if it should append the 'as(..' clause is queried from the pg_proc table but is matched on the parameter types that are passed in, and not on those of the actual proc.

For example, this means that if I passed in say a 'Text' type (25) as opposed to the defined datatype on a proc (eg. 'Varchar' 1043) The select will fail and the extra 'as (...' on the end of the statement in question will not be appended. So the function call will work

Resolution:
I have no idea what the ideal solution is, I don't have a firm understanding of the ins and outs of the provider, but after downloading the source and removing the check so the 'as (...' never gets appended, all CRUD operations in my unit tests pass.

Another suggestion by Al is that maybe it is a piece of code left in there that was needed from a previous version of postgres (since the code has been around for a few years now). Whatever the reason, it causes errors, I've checked the source for another postgres provider and it doesn't attempt to do the append. The only concern I have if this is an actual bug is that it looks as though the same code has been copied into the branch for the npgsql2 provider, so those wanting to use stored procs on postgres in the future may find the same error I have.

The C# @ String Literal

Brendan Kowitz — Mon, 05 Mar 2007 15:10:56 GMT

C# is a pretty sweet language, and there are many, many, many little things that just make the code that much nicer. Have you ever been in a situation where for some reason you NEEDED to have a string/code fragment/js fragment/sql statement inline in your code because you don't believe in resource files or stored procedures?

Aside from whatever great debate about "if you should or shouldn't". If you are going to, please, please, learn to take advantage of what C# has to offer, yes I'm talking about the '@' string literal.

Now I'm not going to target anyone in particular, but my feeling is that VB as a language seems to be more notorious for having hundreds of lines of String.Append()s. String.Append is the absolute worst, hardest and most illegible way of possibly including your fragment inline in code.

There are also the programmers that 'know of' the @ symbol and prefix all their strings with it because it looks cool or something. Doing this without reason may actually alter the behaviour you excepted because it causes escape sequences to NOT be processed.
Eg. "c:\\my\\file.txt" could be done as @"c:\my\file.txt"
This means your \n and \t or whatever it is will also not be processed.

I'd say the most precious and special super power of a string literal is its multi-line ability. So instead of writing code that may look something like:
var1 += @"some text" + Environment.NewLine;
var1 += @"some more text" + Environment.NewLine;
var1 += @"even more text" + Environment.NewLine;

You could just use the @-quoting and write:
var1 = @"some text
some more text
event more text";

And yes that will compile perfectly fine. Best of all, even without going into the debate of "having inline fragments" at least I can read it and change it.

A Free, FreeTextBox Alternative

Tue, 20 Feb 2007 23:57:36 GMT

I don't know why but FreeTextBox has just never cut it for me. It's wonderful and easy to install and it comes as a nice control in a .NET assembly. But it doesn't give you the nicest HTML back, in fact I'd go as far as to say, it mutates GOOD HTML you put in there yourself, this is bad. Luckily there are some other free alternatives such as TinyMCE, which is a nice little editor. The only catch is it's pure javascript and requires a little manual intervention to work with your serverside code.

On a side note: The guys over at CommunityServer probably saw this problem and thought; no matter which editor you pick someone was going to complain, so they implemented the editor control in a Provider model. Clever.

I'm not using CommunityServer so changing my little SUB editor still requires two lines of code change and a recompile, but the flavor of the week for me is Obout's HTML Editor. This little beauty is free for personal use, and commercial use requires only a small registration fee.

This editor not only gives better HTML then FTB but also has some cool things like a Built-in spell checker, quick-formatting and bunches of other little options.

UPDATE(29-Mar-07): I have now had a change to try out FCKEditor, and it does seem to work very smoothly. Also I did notice an option when using it under Mozilla to format 'span' tags rather then the out dated 'font' tags.

It also appears that Obout may have changed their policy since I've made this post because I can no longer see any indication that they want anyone to use the editor for free, they seem to now be pushing downloading it as part of their new suite. So in light of this, FCKEditor may be your best alternative.

Hello IronPython for ASP.NET

Sun, 04 Feb 2007 11:14:35 GMT

Although this is not new news (released November 2006 I think), I'd like to point out how cool having Python run ASP.NET is. I don't actually know how to program python...yet...but programming Python appears intuitive be nature.

To get an HelloWorld IronPython ASP.NET application running, it took me all of about 5 minutes, 3 to download and install the add-in, 1 to open Visual Studio, then another minute to type in some stuff and run it. Sweet. At this point the intellisense has nothing of your other standard languages like C#, but I'm sure that's coming.

One of the biggest issues I see with a a large number of languages is a good IDE. Not to say that Python doesn't already have a number of good IDEs, but, I haven't used an IDE yet that actually beats Visual Studio. So since IronPython can make the effort to actually integrate with Visual Studio and be compatible with all my existing .NET libraries, maybe I'll just have to make more of an effort to check it out.

ASP.NET 2.0 Mozilla Browser Detection Hole

Brendan Kowitz — Mon, 11 Dec 2006 02:58:54 GMT

It has recently come to my attention that there is something drastically wrong with the way search engines have been indexing my ASP.NET 2.0 blog.

As I've started to explain previously, this is because of the way the browser detection is set up. To give a brief rundown ASP.NET 2.0 has a default browser definition which seems to assume that the default browser is fairly capable and supports common things such as javascript and cookies. A browser definition can get inherited into other definitions which can then override specific properties to update it for that specific browser or browser version.

Apparently in around March 2006 Google started rolling out updates that changed the Googlebot's useragent string from:

"Googlebot/2.1 (+http://www.googlebot.com/bot.html)" to
"Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Now the reason for this is so the Googlebot could identify itself as being Mozilla/5.0 compliant which should allow it to be accepted by more webservers. However this breaks the detection pattern in ASP.NET. (And was always broken in Yahoo Slurp, I just don't know if anyone ever noticed).

When the useragent was just "Googlebot/2.1" it wasn't able to be matched and used the "default.browser" detection file which defaulted to a browser of reasonable capabilities. After the change it found itself in the "mozilla.browser" file because it was detected on the "Mozilla" word. So all the following sets of instructions in the "mozilla.browser" file try to establish exactly what platform and variant of Mozilla it is, for example, if its Firefox running on OSX, or if it's the older Mozilla Gecko rendering engine. But because there is no definition for a Generic Mozilla/5.0 compatible browser it gets the most relevant match, being the lowest Mozilla/1.0 compatible settings. Bad!

Because of this bad detection the default Mozilla/1.0 settings assume NO COOKIES and insert the session ID into the url then issues a response status 302 (content temporarily moved). What makes this situation even worse is that the default behavior of search engines is to follow these redirects and index the content on the other side. So basically everytime some random User-agent that claims to be Mozilla/5.0 compliant hits the site it gets Mozilla/1.0 capabilities. What is needed is something to bridge this gap.

Fortunately there is something that can be done that won't even require a recompile of your ASP.NET 2.0 application. Simply create a "genericmozilla5.browser" file in your "/App_Browsers" folder in the root of your application with the following in contents:

<browsers>
<browser id="GenericMozilla5" parentID="Mozilla">
<identification>
<userAgent match="Mozilla/5\.(?'minor'\d+).*[C|c]ompatible; ?(?'browser'.+); ?\+?(http://.+)\)" />
</identification>
<capabilities>
<capability name="majorversion" value="5" />
<capability name="minorversion" value="${minor}" />
<capability name="browser" value="${browser}" />
<capability name="Version" value="5.${minor}" />
<capability name="activexcontrols" value="true" />
<capability name="backgroundsounds" value="true" />
<capability name="cookies" value="true" />
<capability name="css1" value="true" />
<capability name="css2" value="true" />
<capability name="ecmascriptversion" value="1.2" />
<capability name="frames" value="true" />
<capability name="javaapplets" value="true" />
<capability name="javascript" value="true" />
<capability name="jscriptversion" value="5.0" />
<capability name="supportsCallback" value="true" />
<capability name="supportsFileUpload" value="true" />
<capability name="supportsMultilineTextBoxDisplay" value="true" />
<capability name="supportsMaintainScrollPositionOnPostback" value="true" />
<capability name="supportsVCard" value="true" />
<capability name="supportsXmlHttp" value="true" />
<capability name="tables" value="true" />
<capability name="vbscript" value="true" />
<capability name="w3cdomversion" value="1.0" />
<capability name="xml" value="true" />
<capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />
</capabilities>
</browser>
</browsers>

This will match generic Mozilla compatible browsers and spiders with user-agents strings such as:

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
Mozilla/5.0 (compatible; Yahoo! Slurp; http://help.yahoo.com/help/us/ysearch/slurp)
Mozilla/5.0 (compatible; AbiLogicBot/1.0; +http://www.abilogic.com/bot.html)
Mozilla/5.0 (compatible; AnyApexBot/1.0; +http://www.anyapex.com/bot.html)
Mozilla/5.0 (compatible; BecomeBot/3.0; MSIE 6.0 compatible; +http://www.become.com/site_owners.html)
Mozilla/5.0 (compatible; MojeekBot/2.0; http://www.mojeek.com/bot.html)
Mozilla/5.0 (compatible; Scrubby/2.2; +http://www.scrubtheweb.com/)

Other Notes

The MSNBOT also never had this problem because it like the original Googlebot string was never detected and thus received the "default.browser" file settings which support the cookies.

My solution is not a complete fix, I think Microsoft could have done one thing better here. Because the browser string goes into the "mozilla.browser" file, they need another level where when it knows its Mozilla/5.0 compliant it gets the appropriate defaults before it starts to figure out exactly what browser it is. Even though with this approach the exact browsing useragent wouldn't be established, it would at least support future browsers claiming to be compliant at a higher level then just "Mozilla".

Downloads

genericmozilla5.browser