Spatial queries are fun, when you look at them from the outside. Not so fun when you are working to implement them, but that is probably not your concern.

RavenDB had had support for spatial queries for many years now, but the RavenDB 4.0 release has touched on that as well and now you can query spatial data with much greater each. Here is a small sample of how this works:

This query is doing a polygon search for all the employees located inside that polygon. You can visualize the query on the map, we have 4 employees (in yellow) in the viewport and two of them are included within the specified polygon (in blue).

And here is what this looks like in the studio:

In this case, you can see how we support automatic indexing of spatial data. You can also define your own spatial indexes if you need greater control but it is as easy as pie to just go ahead and start running it.

From code, this is just as easy:

I’m not sure why, but when looking at the results, this just feels like magic.

Sometimes, there is no escaping it, and you must accept some user’s input into your system. That sad state of affairs is problematic, because all users have one common tendencies, they are going to be entering weird stuff into your system. And when stuff doesn’t work, you’ll need to make it work, even it make no sense.

Let us take a simple example with this user, shall we?

Assuming that you have a search form for users, and a call goes to the call center, where you need to have the helpdesk staff search for that particular user.

Here are the queries that they tried:

• Stefanie
• Stephenie
• Stefanee
• Stepfanie
• Stephany

Now, you may think poorly of the helpdesk staff (likely outsource and non native speakers), but the same thing can happen for Yasmin, Jasmyne and Jasmyn (I literally took the first two examples I found in Twitter, to show that this is a real issue).

How do you handle something like this? Well, if you are Google, you do this:

What happens if you aren’t Google? Well, since we are talking about RavenDB here, you are going to run a suggestion query, like so:

This requires us to have defined the “Users/Search” index and mark the Name field as viable for suggestions. This tend to be quite computing intensive during indexing time, but it allow us to make a suggestion query on the field, which will give us this result:

What is going on here? During indexing, RavenDB is going to generate a list of permutations of the data that is being indexed. Then, when you run a suggestion query, we can compare the user’s input to the data that has been indexed and suggest possible alternatives to what the user actually entered. This isn’t a generic  selection, it is based on what you actually have in your system.

A more serious case is the international scene. When you have a user such as “André Sørina”:

How do you search for them? On my keyboard, I don’t know how to type this marks (diacritic, I had to search for that). If someone tried to tell me these over the phone, I would be completely lost. It’s a good thing that we have a good solution for that:

Which will give us:

And now we can search for that, and find the user very easily.

This is a feature that we had since 2010, but it got a serious face lift and made easier to use in RavenDB 4.0.

What do you do when you find something you like? If this a favorite dish at a restaurant, you keep order it forever and ever. But if this is something like a good book or a TV show, you’ll typically want to check out similar stuff to enjoy as well. On a more serious note, if you are looking at a bug report, you might want to figure out if there has been other instances of the same issue or similar ones in the past, hopefully as you are typing the bug report.

The feature in general is called More Like This, and it is a nice way to smart up your application. I’m going to use this blog as the example, because More Like This usually requires a significant data set to be meaningful. We are going to define the following index:

And configure the index to use Term Vectors as part of the indexing process:

Once this initial configuration is done, you can now go to RavenDB and ask it to suggest similar posts to an existing one. Here is how this is done:

This ask RavenDB to find posts similar to: PR Review: Encapsulation stops at the assembly boundary, and the result is:

Note that you don’t have to specify an existing document, you can also send the values you want to match on directly:

And this will give you the same results.

RavenDB has a lot of functionality that is available just underneath the surface. In addition to just finding documents, you can use RavenDB to find a lot more about what is going on in your database. This series of posts is aimed at exposing some of the more fun things that you can do with RavenDB that you are probably not aware of.

One of the those things is the idea of not just querying for information, but also querying for the facets of the results. This can be very useful if you are likely to search for something that would return a lot of results and you want to quickly filter these out without having the user do a lot of trial an error. This is one of those cases where it is much easier to explain what is going on with a picture.

Imagine that you are searching for a phone. You might have a good idea what you are looking for a phone on eBay. I just did that and it gave me over 300 thousands results. The problem is that if I actually want to buy one of them, I’m not going to scroll through however many pages of product listings. I need a way to quickly narrow down the selection, and facets allow me to do that, as you can see in the image. Each of these is a facet and I can filter out things so only the stuff that I’m interested in will be shown, allowing me to quickly make a decision (and purchase).

Using the sample dataset in RavenDB, we’ll explore how we can run faceted searches in RavenDB. First, we’ll define the “Products/Search” index:

Using this index, we can now ask RavenDB to give us the facets from this dataset, like so:

This will give us the following results:

And we can inspect each of them in turn:

These are easy, because they give us the count of matching products for each category and supplier. Of more interest to us is the Prices facet.

And here we can see how we sliced and diced the results. We can narrow things further with the user’s choices, of course, let’s check out this query:

Which gives us the following Prices facet:

This means that you can, in a very short order, produce really cool search behavior for your users.