RavenSuggest: A better approach

ASP.NET MVC,jquery,RavenDB 8 July 2012 | 2 Comments

[This post follows on from my first post “RavenSuggest: The wrong approach“. It is aimed at responding to Ayende’s RavenSuggest blog post]

Ok, let me start by saying, its wonderful that Ayende took the time to review my RavenSuggest demo code, that was very demo code. Did I mention it is demo code? I made it public on GitHub as I hate emailing ZIP files of code, oh did I mention its demo code! :)

It has shown some interesting usage of features in RavenDB I hadn’t see before or thought of combing. Reminds of the time at ProgNoSQL where Ayende put together lazy and includes, which resulted in him discovering this bug :)

People love to help!

I got a few Tweets from people regarding my question of if there is a better way than “*term*”. Here they are:

OK. The Twitter RavenDB community has come up with two other options I can see:

Something called “NGramAnalyzer”

“Suggest” API. Hmm. Didn’t think about this, I’ve used it in the past to do things like:

rq.Suggest().Suggestions

To get a list of suggestions if a query doesn’t return any results.

And then Ayende writes a whole blog post of feedback before I get chance to investigate NGramAnalyzer or using Suggest()

Hints of performance problems

I should explain what set off my “this is bad code” gut feeling question to Ayende.

Here is FireBug for 1,500 documents.

Here is FireBug for 30,000 documents.

My bad code spidey senses are tingling! That isn’t scaling very well. Over 200ms, er, that’s not good at all.

Why wasn’t I warned?

I think something RavenDB does rather well is, as Ayende puts it:

That came out of the realization that we had to drop people into the Pit of Success as much as possible.

Ayende (Here)

And as per the RavenDB website, RavenDB is “Safe by default”.

I wouldn’t want RavenDB to throw an exception and stop me doing this, like it would for an N+1 scenario, instead I’d like to be gently informed that what I am doing is rather bad.

I would imagine a purple warning message like this one from when I corrupted RavenDB indexes by pressing the close button and not typing “q” to cleanly shut down.

Wouldn’t something like:

Warning: <<*term*>> can cause performance problems and is considered bad practice.

Have made this blog and the previous unnecessary? (Assuming the documentation is in place to provide an alternative)

That is going a bit more towards the “nanny state” approach but what if I was a developer who didn’t care so much, didn’t read blog, didn’t use Twitter? I could have cause some issues further down the road for other people. I would prefer to be told what I am doing is bad.

It is still demo code

I plan to try and expand it more, but I have merged in Ayende’s comments and they will be live later today.

For example it would be good if they had “Computer Hardware” selected and typed “Bristol” and it showed all results for “Bristol” as well as say “ABC Bristol Ltd”.

I think you can make this even more intelligent.

2 Responses on “RavenSuggest: A better approach”

  1. Phil,
    The reason you weren’t warned is that you explicitly asked for this when you called AllowAllWildcards

    I added the following comment there:

    ///
    /// This allows queries such as Name:*term*, which tend to be much
    /// more expensive and less performant than any other queries.
    /// Consider carefully whatever you really need this, as there are other
    /// alternative for searching without doing extremely expensive leading
    /// wildcard matches.
    ///
    AllowAllWildcards,

  2. Matt Warren says:

    Phil,

    NGram search creates an index that looks like this http://i.imgur.com/Cav99.png, you can see a code sample from Ayende here https://gist.github.com/1669767

Leave a Reply to Ayende Rahien