catch all/wild card matching

[davidmarkclements]

There is no documented way (and appears to be no technical way) of matching against a wildcard value

we want to be able to do

bloomrun.add({}, {meow: 1}) 
bloomrun.lookup({foo: 'bar'}) // {meow: 1}

and

bloomrun.add({foo: /.*/}, {meow: 1}) 
bloomrun.lookup({foo: 'bar'}) // {meow: 1}

[mcdonnelldean]

@davidmarkclements Could you do a slight of hand with the first to light it up? The second should work, if not I know @mcollina wanted it to work like that. It may not be overly performant though (for technical reasons with bloom filters)

[davidmarkclements]

from what I can see the second doesn't work

haven't figured out a way to do the first either - what I'm going for in the first, is an empty object means is an empty pattern which means that if no other patterns match, it still matches empty

[mcdonnelldean]

I'm pretty sure @mcollina wrote some stuff around enabling the second one, it might be in my mails, I will see if I can find it. It was actually a reasonably simple solution but it was a slight of hand. I think the first is as you say but it may be a little slow since the idea of the filter is the make the decision as quick as possible. We could use something like {default$:true} when we know the supplied lookup has no key, that would speed up the match but I don't know how I feel about it... Conflicted

[mcdonnelldean]

@davidmarkclements CF: https://github.com/mcollina/bloomrun/blob/master/lib/deepMatch.js#L6

[davidmarkclements]

so .. we need to be able to add a wild card route, e.g.

var b = require('bloomrun')()
b.add({a: /.*/}, {meow: 1})
b.lookup({a: 'foo'}) // null

[mcdonnelldean]

I've added a bug here. Tests claim we support this, CF regexp support in the pattern But this test is faulty. It is matching due to the second k:v pair.

Both {} and {a: /.*/} are not being correctly stored in the bloom filter I think. @mcollina This may have to do with the magic implementation in the patternSet.js file.

[mcdonnelldean]

All features landed in #32

[mcollina]

I'm against supporting an empty pattern. The reason is that I prefer to be able to differentiate between:

a. there is no matching pattern b. I am applying a default behavior

However, I'm not against implementing this.

A different case is for regexps #33.

[mcdonnelldean]

Closed via #32