Index a composite set of fields

[paulbjensen]

For context, an example document:

var document = {"id": 1,"first_name":"Paul", "last_name":"Jensen"};

And an example of the index I would like to construct and consume:

var index = lunr(function () {
  this.field(['first_name', 'last_name'])
  this.ref('id')
})

index.add(document);

index.search("Paul Jensen");

A question that comes to mind is how to make that composite index pad the fields with a space between them. Alternatively, I imagined that a function may be a better option:

this.field(function(doc){return doc.first_name + " " + doc.last_name});

[paulbjensen]

I've started implementing this feature in a fork here: https://github.com/axisto-live/lunr.js

I think that a better approach would be to pass an function to the options, like so:

var index = lunr(function () {
  this.field('full_name', { value: function (doc) { return [doc.first_name, doc.last_name].join(" ") } })
})

I'm not sure if value is the best name for the options property, but it can change pretty easy.

[olivernn]

Does your example work e.g. this.field(['first_name', 'last_name'])?

I'm leaning more towards lunr being as simple as possible, and for your use case, indexing a composite field, I think it is easy enough to achieve what you need without adding code to lunr. You would just have some function that maps your document to whatever needs to be indexed in JavaScript. You could wrap lunr's add method to do this for you, e.g.

var idx = lunr(function () {
    // your config here…
})

idx.add = function (doc) {
    var indexableDoc = $.extend({}, doc, {
        full_name: [doc.first_name, doc.last_name].join(' ')
    })

    return lunr.Index.prototype.add.call(this, indexableDoc)
}

I think this might be better, just because how you convert you domain object to something that can be indexed by lunr could be fairly app specific.

Having said that you are not the first person to ask for this feature, so I'll try and think of some use cases where having lunr do the work would make more sense than your application.

[paulbjensen]

Addresses are another example where a composite index could be useful.

After having some Coffee, I realised that my first suggestion (passing an array) was a terrible idea. The 2nd comment has a better approach, but I've renamed the value option to "compose". I'll experiment a bit more.

[paulbjensen]

So we didn't need this feature in the end. It turned out that the format in which the query was being sent was malformed, hence it wouldn't match.

I'm going to close this issue as...

    ___           ___           ___           ___                 
   |\__\         /\  \         /\  \         /\__\          ___   
   |:|  |       /::\  \       /::\  \       /::|  |        /\  \  
   |:|  |      /:/\:\  \     /:/\:\  \     /:|:|  |        \:\  \ 
   |:|__|__   /::\~\:\  \   /:/  \:\  \   /:/|:|  |__      /::\__\
   /::::\__\ /:/\:\ \:\__\ /:/__/_\:\__\ /:/ |:| /\__\  __/:/\/__/
  /:/~~/~    \/__\:\/:/  / \:\  /\ \/__/ \/__|:|/:/  / /\/:/  /   
 /:/  /           \::/  /   \:\ \:\__\       |:/:/  /  \::/__/    
 \/__/            /:/  /     \:\/:/  /       |::/  /    \:\__\    
                 /:/  /       \::/  /        /:/  /      \/__/    
                 \/__/         \/__/         \/__/                

[olivernn]

Ah cool, as you say, I think this is something that is better kept out of lunr because most people wont need it.

:+1: for the ascii art too!