{"id":4213,"date":"2015-10-29T10:24:36","date_gmt":"2015-10-29T10:24:36","guid":{"rendered":"https:\/\/ushipblogsubd.wpengine.com\/?p=4213"},"modified":"2025-09-03T16:05:33","modified_gmt":"2025-09-03T16:05:33","slug":"nhibernatemare-elm-street","status":"publish","type":"post","link":"https:\/\/ushipblogsubd.wpengine.com\/shipping-code\/nhibernatemare-elm-street\/","title":{"rendered":"An NHibernateMARE on Elm Street"},"content":{"rendered":"

We use (and generally like) the ORM<\/a> NHibernate<\/a> for MS SQL Server data access, but we understand why you might not.\u00a0Ohhhh, the things we have seen! We\u2019d like to share some of our favorite horrors, so that you can avoid them.<\/p>\n

\n

\"It
\nOriginally, our Repository<TEntity><\/tt> base class implemented IEnumerable<TEntity><\/tt>. This allowed us to do clever things like<\/p>\n

    foreach (var c in CountryRepository) { \/* \u2026 *\/ }\r\n<\/pre>\n
This simple iteration was handy, especially for reference tables (e.g., Countries, States\/Provinces, categories of shippable things). This “feature” turned out to be a giant, carnivorous bug. Why you ask? Because LINQ is powerful magic.<\/p>\n
It first started when instead of IUserRepository.Get(userId)<\/tt> someone wrote IUserRepository.First(x => x.UserId == userId)<\/tt>. Let’s take a look at the SQL that is generated by these statements.<\/p>\n
    -- IUserRepository.Get(userId)\r\n\r\n    SELECT\r\n        users0_.Id as Id2_0_,\r\n        users0_.Username as Username2_0_,\r\n        -- ...\r\n    FROM\r\n        [Users] users0_ \r\n    WHERE\r\n        users0_.Id=@p0;\r\n<\/pre>\n
But notice the missing WHERE<\/tt> clause in this next case:<\/p>\n
    -- IUserRepository.First(x => x.UserId == userId)\r\n\r\n    SELECT\r\n        users0_.Id as Id2_0_,\r\n        users0_.Username as Username2_0_,\r\n        -- ...\r\n    FROM\r\n        [Users] users0_\r\n<\/pre>\n
What’s really happening in the latter case is that the code we accidentally wrote is<\/p>\n
    Enumerable.First(session.Query(), u => u.Id == usersId)\r\n<\/pre>\n
instead of what the developer thought<\/em> they were writing:<\/p>\n
    Queryable.First(session.Query(), u => u.Id == userId)\r\n<\/pre>\n
Unless you don\u2019t mind loading your entire User’s table into memory every time you look someone up (for us this only took 12 GB of RAM), don\u2019t allow your Repositories to implement IEnumerable.<\/p>\n
\n
\"L?t
\nWe can\u2019t tell you whether you should use nvarchar<\/tt> or varchar<\/tt> in your application, but we can say that the mappings for varchar<\/tt> suck (hint: start by using .Map(...).CustomType(\"AnsiString\")<\/tt> to map your varchar<\/tt> mappings). Regardless of what you choose, you must know exactly what values you\u2019re putting into your database, and equally important, what you\u2019re getting back out.<\/p>\n
The problem: this guy \u0ca0_\u0ca0<\/span><\/p>\n
Or rather, the guy who chose that as his username.<\/p>\n
First we mapped an Entity\u2019s string property to a varchar<\/tt> column (non-Unicode string data) instead of nvarchar<\/tt> (Unicode string data). However, what we actually store in the database as his username is “?_?<\/tt>” since every high Unicode character is stored as a single question mark.<\/p>\n
Second, we included a non-slug-ified, user-defined value (username) in the canonical URI of an API resource. In other words, the username “JohnDoe” would be included in the API URI as the path<\/p>\n
    \/users\/johndoe\r\n<\/pre>\n
But that<\/em> guy\u2026 his URI is<\/p>\n
    \/users\/?_?\r\n<\/pre>\n
Got that? We made this transformation by mistake:<\/p>\n
\"disapprovingface\"<\/p>\n
we turned his disapproving face into tears<\/p>\n
For anyone who knows RFC-3986<\/a>, you will understand why this doesn\u2019t work. ‘?<\/tt>‘ separates the path from the query in a URI. Sadly it took us a few users who were unable to retrieve their profiles before we figured this one out.<\/p>\n
Here’s the lesson: Know what you\u2019re storing in your database. If you choose to store non-Unicode string data, prohibit arbitrary Unicode characters in data entry and user input validation. Otherwise, this is how we feel about you: \u0ca0_\u0ca0<\/p>\n
\n
\"Night<\/p>\n
You can\u2019t have a Halloween blog without zombies<\/a>, right?<\/p>\n
Suppose you’re programming along, minding your own business, using your oh-so-convenient Session-per-Request pattern, when you come upon a stack trace containing CheckNotZombied()<\/tt>. In our case, this is another issue that arose from the intersection of a couple different problems.<\/p>\n
At first we came across a blog stating this can be caused by one of two problems:<\/p>\n