The Lazy Man's Comprehensive RavenDB Search

RavenDB supports many types of searches, and in this case, I want to show something that belongs to the cool parts of the pile, but also on the “you probably don’t really want to do this”.

First, let me explain why this is cool, then we will talk about why you probably don’t want to do that (and finally, about scenarios where you actually do want this).

Here is an index that will allow you to search over all of the values of all of the properties in the user entity:

    public class Users_AllProperties : AbstractIndexCreationTask<User, Users_AllProperties.Result>
    {
        public class Result
        {
            public string Query { get; set; }
        }
        public Users_AllProperties()
        {
            Map = users =>
                  from user in users
                  select new
                  {
                      Query = AsDocument(user).Select(x => x.Value)
                  };
            Index(x=>x.Query, FieldIndexing.Analyzed);
        }
    }

This can be easily query for things like:

    s.Query<Users_AllProperties.Result, Users_AllProperties>()
        .Where(x=>x.Query == "Ayende") // search first name
        .As<User>()
        .ToList()


    s.Query<Users_AllProperties.Result, Users_AllProperties>()
        .Where(x=>x.Query == "Rahien") // search last name
        .As<User>()
        .ToList()

The fun part is that because we are actually going to index all the properties values into the Query field, which then allow us to easily query for every one of the values without any trouble.

The problem with that is that this is also quite wasteful and likely to lead to bad results down the road. Why?

For two major reasons. First, because this is going to index everything, and would result in larger index, more IO, etc. The second reason is that it is going to lead to bad results because you are now searching over everything, including the “last login date” and the “password hint”. That means that your search results relevancy is going to be poor.

So why would you ever want to do something like that if it is bad?

Well, there are a few scenarios where this is applicable. You need to do that if you want to be able to search over completely / mostly dynamic entities. And you want to do that if you have entities which are specifically generated for the purpose of being searched.

Both cases are fairly rare (the first case is usually covered by dynamic indexing, anyway), so I wanted to point this out, and also point out that it is usually far better to just specify what are the fields that actually matter for you.