NHibernate

Sqlite-Csharp and NHibernate

Rob Ashton — Mon, 07 Jun 2010 21:44:31 GMT

Taking a brief interlude from my RavenDB series, I was doing some work on an internal project tonight with the build scripts and test-runner and I finally got bored of having to deal with un-managed SQLite dependencies with a project which other than that was platform agnostic.

The problem with having un-managed dependencies in a managed project is that Visual Studio quite frankly sucks at it, you can set up certain projects (in this case the tests) to be x86 only, and remove their Any CPU configuration – but as soon as you add a new project to the solution it decides to re-add the old configuration and potentially break things again.

This doesn't really rear any problems until you write a build script and things start falling over as your test runner tries to run as an x64 process and tries to load in the x86 dependency, or any number of combinations where this kind of thing can blow up. If it can happen, it will happen and it’s just something I’d rather not deal with.

So I had a look at Sqlite-Csharp, the code is atrocious as far as natively written C# libraries go (that’s not the point though, it’s a *port*), but it looks to be a superb direct-port of a C project (Sqlite) and passes most of the tests that it needs to in order for it to be viable for use in at least our in-memory tests.

Anyway, you can’t download binaries, so you have to build it – but no changes are required so just do it.

I’m not going to cover the process of setting up in-memory databases for testing with SQLite as that’s an easily Google-able topic, but there are a few differences between doing it with the unmanaged libraries and with the pure managed libraries.

This is what my FluentNHibernate configuration looks like:

   1:  Fluently.Configure()

   2:              .Database(

   3:                   SQLiteConfiguration.Standard.ConnectionString(

   4:                        x => x.Is(mConnectionString)).Driver<SqliteDriver>());

I’ve had to create a driver to make this work properly as there isn’t one provided as stock in NHibernate, the code for this is as simple as this:

   1:  public class SqliteDriver : ReflectionBasedDriver

   2:      {

   3:          /// <summary>

   4:          /// Initializes a new instance of <see cref="SQLiteDriver"/>.

   5:          /// </summary>

   6:          /// <exception cref="HibernateException">

   7:          /// Thrown when the <c>Community.CsharpSqlite.SQLiteClient</c> assembly can not be loaded.

   8:          /// </exception>

   9:          public SqliteDriver()

  10:              : base(

  11:                  "Community.CsharpSqlite.SQLiteClient",

  12:                  "Community.CsharpSqlite.SQLiteClient.SqliteConnection",

  13:                  "Community.CsharpSqlite.SQLiteClient.SqliteCommand")

  14:          {

  15:          }

16:

  17:          public override bool UseNamedPrefixInSql

  18:          {

  19:              get { return true; }

  20:          }

21:

  22:          public override bool UseNamedPrefixInParameter

  23:          {

  24:              get { return true; }

  25:          }

26:

  27:          public override string NamedPrefix

  28:          {

  29:              get { return "@"; }

  30:          }

31:

  32:          public override bool SupportsMultipleOpenReaders

  33:          {

  34:              get { return false; }

  35:          }

36:

  37:          public override bool SupportsMultipleQueries

  38:          {

  39:              get { return true; }

  40:          }

  41:      }

Yeah, not terribly exciting – just add a reference to Community.CsharpSqlite.SQLiteClient and this will work.

The other major difference is the delimiter between connection string components is a comma and the method of selecting an in-memory database looks different. This is my connection string:

   1:  "uri=file://:memory:,Version=3";

And this is the code I use to create the connection:

   1:  private SqliteConnection GetConnection()

   2:          {

   3:              if (mConnection == null) {

   4:                  mConnection = new SqliteConnection(mConnectionString);

   5:                  mConnection.Open();

   6:              }

   7:              return mConnection;

   8:          }

And this is therefore the code I use to create a session factory:

   1:  mFactory.OpenSession(GetConnection());

A word of warning

Mileage may vary, I had 11 tests from about 300 fail, mostly due to unrecognised types/null values and exceptions that were different in this version of Sqlite, I’m submitting some code fixes for the unrecognised types and null values and modifying my tests to take into account the new exception types.

Also, I can’t guarantee I’ve done it right, so let me know if I’ve done something stupid.

All of my tests are now Any CPU and my build process is suddenly a lot simpler, I’ll take the hit of having to submit and change a bit of code in order to get that.

Why Linq2NHibernate isn't ready for production use

Rob Ashton — Wed, 21 Oct 2009 23:00:00 GMT

I was quite excited when Ayende announced that he had written a Linq provider for NHibernate which was of production quality.

It came with a few caveats, it could only do what criteria currently supported and they hadn't implemented any sort of join support. I considered these to be perfectly reasonable items on the todo list, given that they are actively working on creating a more complete linq provider that does everything people would want it to do.

I do the vast bulk of my queries using the criteria API, written as specifications against thin repositories, and adding a LinqSpecification was a simple task. I decided that given the limitations described above to follow a few simple rules for when I could use a Linq query such as "only use Linq when querying the properties of a single type of object".

Having Linq in my specifications gave some real benefits, such as strong typing and compile time support for checking the properties being queried against. Normally if you change the name of a property on any domain object and forget to update the text in a criteria or hql query you'd only catch this when you ran your unit tests. (Or worse, during product testing/use!)

I was using it quite happily for a week or so until I stopped to review the sql it was generating under the hood for even the simplest of queries.

Consider the following objects:

    public class Blog
    {
        public virtual int Id
        {
            get;
            protected set;
        }

        public virtual String Name
        {
            get;
            set;
        }
    }

    public class BlogEntry
    {
        public virtual int Id
        {
            get;
            set;
        }

        public virtual Blog Blog
        {
            get;
            set;
        }

        public virtual String Content
        {
            get;
            set;
        }
    }

With the following mappings:

    public class BlogMap : ClassMap<Blog>
    {
        public BlogMap()
        {
            Id(x => x.Id);
            Map(x => x.Name).Not.Nullable();
        }
    }

    public class BlogEntryMap : ClassMap<BlogEntry>
    {
        public BlogEntryMap()
        {
            Id(x => x.Id);
            Map(x => x.Content).Not.Nullable();
            References(x => x.Blog).Not.Nullable();
        }
    }

Fairly straight forward stuff. Now imagine I have a blog object in hand and I wish to query for all the entries that belong to that blog (We could easily imagine asking this being a query where we ask for the entries from that blog between a certain date range).

The query looks something like this:

            var linqResults = (
                        from entry in session.Linq<BlogEntry>()
                        where entry.Blog  == blog
                        select entry
                      ).ToList();

Again, very straight forward - and you'd expect the query to be so as well - so have a look!

SELECT this_.Id as Id1_1_, this_.Content as Content1_1_, this_.Blog_id as Blog3_1_1_, blog1_.Id as Id0_0_, blog1_.Name as Name0_0_ FROM "BlogEntry" this_ left outer join "Blog" blog1_ on t his_.Blog_id=blog1_.Id WHERE this_.Blog_id = @p0;@p0 = 1

What WHAAT?!

If you can't see the problem here then go and ask your DBA if you have one, because I can guarantee they'll not be happy if you start littering your specifications with this kind of query.

Why are we doing a join to the Blog table? We don't need to do a join to the Blog table, we should be comparing the id situated in the BlogEntry table.
Why are we bringing back al the information from the blog table as well as the blog entry? Imagine you're bringing back 50 such blog entries - you'd be bringing back 50 identical blog objects too.
It's a left outer join too, your DBA is going to hit the roof! (Mine definitely would - you should only be using these where it makes sense to be using them.

Check out the equivalent Criteria based query:

            var criteria = session.CreateCriteria<BlogEntry>()
                                .Add(Restrictions.Eq("Blog", blog)).List<BlogEntry>();

Generating the following SQL:

SELECT this_.Id as Id1_0_, this_.Content as Content1_0_, this_.Blog_id as Blog3_1_0_ FROM "BlogEntry" this_ WHERE this_.Blog_id = @p0;@p0 = 1

Much more sensible.

You might be of the persuasion that you don't really care, and that's acceptable in some cases I guess- but I'm of the opinion that if all of your queries look like the above then you've got some real issues. Our product has to service the needs of some fairly large customers with some fairly heavy load and the system chugging at all is going to get us in a lot of trouble.

Take for example the following (perfectly reasonable) query if our objects were a little more complex.

            var complexResult = (
                    from entry in session.Linq<BlogEntry>()
                    where entry.Category == category &&  entry.Blog.User == user
                    select entry
                ).ToList();

This will generate the following SQL:

SELECT this_.Id as Id1_3_, this_.Content as Content1_3_, this_.Blog_id as Blog3_1_3_, this_.Category_id as Category4_1_3_, blog2_.Id as Id0_0_, blog2_.Name as Name0_0_, blog2_.User_id as User3_0_0_, user3_.Id as Id3_1_, user3_.Name as Name3_1_, category1_.Id as Id2_2_, category1_.Name as Name2_2_ FROM "BlogEntry" this_ left outer join "Blog" blog2_ on this_.Blog_id=blog2_.Id left outer join "User" user3_ on blog2_.User_id=user3_.Id left outer join "Category" category1_ on this_.Category_id=category1_.Id WHERE (this_.Category_id = @p0 and blog2_.User_id = @p1);@p0 = 1, @p1 = 1

Every single property of every single referenced object being brought back even though I've only asked for BlogEntry.

Without trying to sound like a complete arse, this is not the definition of production quality I am familar with!

I really do look forward to the proper release of Linq2NHibernate, but until then I'm sticking to Hql And Criteria because I can trust them to keep my DBA happy.

Technorati tags: NHibernate, Linq2NHibernate, Linq, .NET