Ayende @ Rahien

It's a girl

Lazy’s Man comprehensive search with RavenDB

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.

Tags:

Posted By: Ayende Rahien

Published at

Originally posted at

Comments

Oded
04/25/2012 09:05 AM by
Oded

The search for first name is identical to the search for last name in your examples.

Did you mean them to be identical?

P
04/25/2012 01:24 PM by
P

Forgive me for my ignorance, but could you just use full-text search capabilities in Lucene to search all users for some piece of data matching your input?

What is the difference between full text search and indexing every property and using LINQ?

Karep
04/25/2012 05:33 PM by
Karep

Is there any documentation for Lucene.net? It very hard to find it.

Christopher Wright
04/26/2012 01:22 AM by
Christopher Wright

Will this result in indexing field names? So if I search for 'firstname', it'll hit every single User document?

Ayende Rahien
04/26/2012 07:52 AM by
Ayende Rahien

Karep, It is the same as for Lucene, here: http://lucene.apache.org/core/

Ayende Rahien
04/26/2012 07:52 AM by
Ayende Rahien

Christopher, No, it wouldn't create individual fields, you can do that, too, but as I said, that is a REALLY bad idea in most cases.

Karep
04/26/2012 08:55 AM by
Karep

Ayende, so when You create indexes in Raven you really are creating Lucene.Net indexes? Are those indexes (Map, Index) some kind of wrappers, syntactic sugar for Lucene indexes? Also all examples for Lucene I saw show storing those indexes in files on disk. Is it exactly what you do or store them some way 'inside' RavenDB?

Comments have been closed on this topic.