“The overloads for DropDownList and ListBox helper methods were reworked to fix various usability problems that were reported by customers.”

Thanks for listening!

Compiler Error Message: CS0433: The type 'System.Web.Mvc.FormMethod' exists in both 'c:\WINDOWS\assembly\GAC_MSIL\System.Web.Mvc\1.0.0.0__31bf3856ad364e35\System.Web.Mvc.dll' and 'c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\root\06c0b3cf\32bec25d\assembly\dl3\71bfb65b\e11bf5c5_9e55c901\System.Web.Mvc.DLL'

I am using my own build of the source from codeplex so that I can debug through it to improve my knowledge of the codebase. From research online it looks like the assembly version between the latest pre-release and the beta weren’t incremented, or the web-runner tries to look in the GAC before the /bin, or the evil garden gnomes are at it again, or Microsoft wants to punish me for building THEIR dll files.

To solve this problem, i opened up the AssemblyInfo.cs files of the Mvc project and upped the AssemblyVersion to 1.0.0.9. Then hacked my web config to use that version. As I’m running in debug mode, and can’t sign the assembly I also had to remove the PublicKeyToken from the reference.

<add assembly="System.Web.Mvc, Version=1.0.0.9, Culture=neutral"/>

And suddenly we’re back in business.

One solution is to create an extension method to trim down the DateTime to only include valid values in a deterministic way as follows:

    public static class DateTimeExtensions

    {

        private static readonly DateTime minSqlDateTime = DateTime.Parse("1/1/1753 12:00:00 AM");

        public static DateTime ToSqlDateTime(this DateTime dt)

        {

            if (dt < minSqlDateTime)

                dt = minSqlDateTime;

            return new DateTime(dt.Ticks - (dt.Ticks % 10000000));            

        }

    }

Note that this is designed for SQL Server. Other database types may need different levels of precision.

Instead you could implement a custom IUserType for NHibernate which tells NHibernate how to translate a DateTime that is out of bounds into one that is in bounds such as:

    public class SqlDateTimeUserType : IEnhancedUserType

    {

        private static readonly DateTime minSqlDateTime = DateTime.Parse("1/1/1753 12:00:00 AM");

        public new bool Equals(object x, object y)

        {

            return x == null ? y == null : x.Equals(y);

        }

        public Type ReturnedType

        {

            get { return typeof(DateTime); }

        }

        public SqlType[] SqlTypes

        {

            get { return new[] { NHibernateUtil.DateTime.SqlType }; }

        }

        public int GetHashCode(object x)

        {

            return x.GetHashCode();

        }

        public object NullSafeGet(IDataReader dr, string[] names, object owner)

        {

            //no need to alter values coming out of the database

            DateTime? obj = NHibernateUtil.DateTime.NullSafeGet(dr, names[0]) as DateTime?;

            return obj == null ? ToSqlDateTime(DateTime.MinValue) : obj.Value;

        }

        public void NullSafeSet(IDbCommand cmd, object obj, int index)

        {

            //set it to a safe value going into the database

            ((IDataParameter)cmd.Parameters[index]).Value = ToSqlDateTime((DateTime)obj);

        }

        public object DeepCopy(object value)

        {

            return value;

        }

        public object Replace(object original, object target, object owner)

        {

            return original;

        }

        public object Assemble(object cached, object owner)

        {

            return cached;

        }

        public object Disassemble(object value)

        {

            return value;

        }

        public bool IsMutable

        {

            get { return false; }

        }

        public object FromXMLString(string xml)

        {

            return DateTime.Parse(xml);

        }

        public string ObjectToSQLString(object value)

        {

            return value as string;

        }

        public string ToXMLString(object value)

        {

            return value as string;

        }

        private static DateTime ToSqlDateTime(DateTime dt)

        {

            if (dt < minSqlDateTime)

                dt = minSqlDateTime;

            return new DateTime(dt.Ticks - (dt.Ticks % 10000000));

        }

    }

These user types are mapped as follows:

    <property name="ImportDate" type="Framework.SqlDateTimeUserType, Framework"/>

The only problem with this is that a simple test such as the following will fail:

        [Test]

        public void CanSaveBadValuesToImportDate()

        {

            With.AutoRollbackTransaction(() =>

            {

                Product p = new Product("Apples");

                p.ImportDate = DateTime.MinValue;

                Session.Save(p);

                Session.Flush();

                Session.Clear();

                Product p2 = Session.Load<Product>(p.Id);

                Assert.AreEqual(p.Name,p2.Name);

                Assert.AreEqual(p.ImportDate, p2.ImportDate); //fails here

            });

        }

We could try and create a bunch of edge conditions on our converter such as:

        public object NullSafeGet(IDataReader dr, string[] names, object owner)

        {

            DateTime? obj = NHibernateUtil.DateTime.NullSafeGet(dr, names[0]) as DateTime?;

            if (obj != null && obj == minSqlDateTime)

                return DateTime.MinValue;

            return obj == null ? ToSqlDateTime(DateTime.MinValue) : obj.Value;

        }

But that could get out of hand in a hurry. It also would cause errors if you stored DateTime.MinValue.AddSeconds(1). If we wanted to go really over the top, we could create our own class that implements operator DateTime (explicit and implicit) which would do the conversion to a SQL range when we first assign a value. This would solve both problems, but you’d end up with your domain needing a special DateTime class for all of your entities instead of using the built in. Your call…

I thought I’d mention it to this group so that people were aware of this difference between the interaction the old ParameterBinders and Rescues in version 4 and the new ModelBinders and HandleErrorAttributes of version 5.

The new way of doing parameter binding expects all errors to be placed into the ModelStateDictionary specified in the GetValue method.
public override object GetValue(ControllerContext controllerContext, string modelName, Type modelType, ModelStateDictionary modelState) {

The ModelStateDictionary can then be checked in the controller for errors via ViewData.ModelState.IsValid

I think the idea is that multiple binding errors can then be reported to the user at one time:
foreach (var value in ViewData.ModelState.Values)
{
value.Errors…..
}

Unfortunatly our current NameValueDeserializer that is used by the DeserializeAttribute throws exceptions when it encounters errors. These exceptions are NOT caught by Rescues / HandleErrorAttributes. The ControllerActionInvoker (in preview 5) calls

IDictionary parameters = GetParameterValues(methodInfo);

before the try/catch block that passes off errors to the HandleErrorAttributes. So if you’re using any kind of attribute deserialization and expecting your exceptions to be displayed all pretty like in your rescues… then move line #177 to line #180 of your ControllerActionInvoker.cs :)

-Will

        public static void Save(this ISession session, params object [] entities)

        {

            foreach (var o in entities)

            {

                session.Save(o);

            }

        }

You can use it like:

session.Save(a,b,c,d,….);

with a list of objects of any type. Useful for unit testing where you want to save multiple items at once.

[Update]

Probably should call it something other than Save, such as SaveAll or SaveList because if you only pass two items to the overload it calls the standard Save(object, int id) version. :(

It is used any time you would previously call CreateCriteria and pass an alias.
Before:
session.CreateCriteria(typeof (Product)).CreateCriteria(“Orders”,”Product_Orders”);
After:
session.CreateCriteria(typeof(Product)).CriteriaByLongAlias(“Orders”);

The alias part is done automatically based on the criteria path. The advantage is that it works recursively, allowing for multiple criteria to be created, and then referenced without duplicates.

ICriteria criteria = session.CreateCriteria(typeof(Product)).CriteriaByLongAlias(“Orders”).CriteriaByLongAlias(“Customer”).Add(Expression.Eq(“Name”, “Ace Hardware”));
criteria.CriteriaByLongAlias(“Orders”).Add(Expression.Eq(“OrderNumber”,12354));

etc.

Note that in order for it to work, you have to create all your subcriteria with it.

-Will

My most recent change set was updating the Criteria Query API to allow for queries involving HAVING clauses. In performing this change I also discovered a bug whereby complicated queries would get parameters out of order. In this post I will cover:

• The feature added (need and implementation)
• Determining problem need
• Hints for getting your patch accepted

The Feature

The Criteria Query API provides some valuable tools for creating dynamic queries without doing crazy string manipulation (yuck). I had a situation where I wanted to validate entities to check for duplicates prior to the transaction being committed. Because of the temporal nature of the project I’m working on, I can’t do it with a table constraint or other simple means and need to check valid dates.

To solve it with HQL would involved about 10 lines of messy reflection and string concats where solving it with the criteria API took about 4. Here’s the code:

ICriteria criteria = session.CreateCriteria(typeof(Person));
criteria.SetProjection(Projections.ProjectionList()
  .Add(Projections.Max("Id"))
  .Add(Projections.GroupProperty("Name")))
  .ProjectionCriteria.Add(Restrictions.Gt(Projections.Count("Name"), 1));

The resulting SQL for this code should be:

"SELECT MAX(Id), Name FROM Person GROUP BY Name HAVING COUNT(Name) > 1"

Imagine my surprise when this relatively simple Criteria Query failed while the same HQL query succeeded. After examining the SQL it produced I determined that there was no HAVING clause being produced.

Fearing that I was doing something wrong I opened up the source code for NHibernate and performed a textual search for “having” as I knew that at some point it must be produced by the SQL generator. I was unable to locate anything in the Criteria API that was even remotely related to HAVING queries.

Having exhausted that possibility I posted to the google nhusers group to make sure that I wasn’t missing something. After some discussion it was obvious that this was indeed a lacking feature and that it would be appreciated by the community.

After determining that it was indeed a problem with the codebase I launched into patching it. I wrote test cases to be able to debug into the code in the Criteria interface. I recommend adding the folder for your tests as:
\src\NHibernate.Test\NHSpecificTest\NH1999
Then migrating it to the specific issue number after you’ve made progress enough to report the issue. This prevents nasty collision problems if someone else takes the next number.
\src\NHibernate.Test\NHSpecificTest\NH1280
I’ve also recently taken to adding a description after the folder such as “NH1291AnonExample” in my latest patch. This makes it easier to determine which set of tests has failed for other developers.

The patch itself is rather complicated and out of the scope of this post as it contained changes to almost 50 files. In writing the patch I tried a couple of different methods for adding my features and even had to revert a couple of files from the source. I worked from the output to the input, backing out from the SQL generator to the individual Criteria and Criterion classes.

As I wrote the patch I made sure that I didn’t negatively impact other use cases. If your patch breaks other tests it won’t be accepted even if it implements “teh best featre evar”! For added tests I merged my changes into both my active work project and the Linq to NHibernate project. Doing so revealed cases that I hadn’t considered in my initial tests and allowed me to add in those tests and deliver a more solid patch.

Before submitting any patch I always go through a cleanup of my changed code. This involved going through my patch file by file making sure that I’m only submitting code that pertains to the patch and only changes things that need to be changed. (Using TortoiseSVN this is quite simple, folder menu -> check for modifications)

I try and keep my formatting changes to a minimum. Resist the urge to re-arrange existing code, convert tabs to spaces etc. While NHibernate and many other open source projects could use some cleanup work, that should be performed by dedicated committers. In our case the organization is loosely tied to the Hibernate project and would make it more difficult to port newer features if the NHibernate code is re-arranged.

Submit the patch and leave a clear explanation of the problem it solves and how it solves it. Best of luck and thanks for contributing to the project!

Today I was working on a JSON to NHibernate bridge when I came across something quite frustrating when trying to convert strings to other types. In this bridge object I’m persisting an object out of the database with NHibernate, then assigning the new values from the JSON string to that object. (Or list of objects.)

This seemed simple enough. I was thinking that it should be easy enough to write a loop that looks at the javascript keys {“Key”:”Value”} and matches them up with the PropertyInfo of the target object. This is trivial when both are strings, but what if the target type is a float, int, bool, date, enum etc?

Most base types have a Parse method of some kind that looks like Parse(string) or Parse(string, IFormatProvider). Here’s a couple of types that implement some variant of the Parse method.

This leaves me with only one question?

Where’s my Interface?

I can’t do a test for IParseable on the object, I can’t even search for the parse method by name and parameters because each object implements them differently. I could go with only the string parameter which they all implement, but I’ve learned from Civ4 that culture is important, and besides I wouldn’t want to fail the Turkey test.

Of course there’s a reason for this seemingly lazy design – interfaces can’t be declared as static. (That’s a conversation for a different day.) Ok, so given that they can’t, where do we go from here? Lets pretend that we still wanted to use an Interface for these classes.

So now we’ve got an Empty Interface. Perhaps this would be better as a custom attribute, and if so please explain to me how to accomplish this next part with said custom attribute.

We then assign our interface to the DataType and implement a number of Parse methods

Then in the System.Convert class we’d implement some function like this:

Other methods could accept CultureInfo, FormatProviders and other params. Someone have a better way of doing this?