Feature: Custom search function

[no-more]

Hi,

Do you think it would be possible to pass a custom search function in find function ? It would be great to be able to mix the default search feature (more performant, can use index ...) but also to include a custom search function in order to implement some very specific search ?

Thanks a lot.

[Irrelon]

There is an undocumented method in the Collection class called filter:

/**
 * Executes a method against each document that matches query and returns an
 * array of documents that may have been modified by the method.
 * @param {Object} query The query object.
 * @param {Function} func The method that each document is passed to. If this method
 * returns false for a particular document it is excluded from the results.
 * @param {Object=} options Optional options object.
 * @returns {Array}
 */
Collection.prototype.filter = function (query, func, options) {
    return (this.find(query, options)).filter(func);
};

I believe this will satisfy your requirement :) let me know if it helps!

[Irrelon]

Keep in mind that this is not in the documentation yet because I haven't decided if the order of the arguments is correct or not. I am wondering if the order should be "query, options, func" instead of "query, func, options".

Arguments for "query, func, options":

Unlikely that many users will need the options object so leave it to last to allow it to be unspecified.

Arguments for "query, options, func":

Matches standard query method and includes func at end like a callback would be. If options is a type of function we can assume no options object.

[Irrelon]

In fact I've just pretty-much talked myself into changing to "query, options, func" with an optional query and optional options.

Gonna make that change now...

[Irrelon]

Also I wasn't sure if the process should allow for an async callback style system or just return data as an array immediately. I'm leaning towards async at this point.

[no-more]

Hi,

Thanks that's looks great.

Sadly I will not be able to test it before a few weeks as I have to complete something else first.

About async, maybe you could just provide 2 methods ? filter and filterSync (or filter and filterAsync if you prefer to keep the sync methods first)?

Thanks.

[Irrelon]

We could do the filterSync and filter in a node-style. I guess this goes to a larger argument about all the methods in ForerunnerDB and if we want to segregate them all like this in version 2.0.

We may also want to just make all operations async and allow both callback and promise style usage. We could even support all three types of usage theoretically but obviously return-based style would only work in some instances so that could end up confusing users more than helping them.

When I wrote the original version of ForerunnerDB it was entirely sync code. We didn't need async at all.

Then I added persistence because some users asked for it and that started a wave of updates that started moving code to supporting async stuff.

Going forward for version 2.0 I think we should probably only support an async usage and allow both callback and promise-based code. It is a bit messier from the calling code point of view since sync code is easier to read and follow but I'm not sure how else to support a fully async pipeline without it unless everyone adopts that language I wrote (SyncScript) :)

What do you think?

[Irrelon]

OK I have just pushed version 1.4.1. This version has the new filter() method with "query, options, func" argument order. It is on the dev branch at the moment and is passing all 3,493 test assertions on the test suite (so safe to use in production).

[no-more]

I think fully async is best than fully sync.

Sync is really great for readability, but with async/await feature coming soon in javascript (at least I hope so) async code is definitly the way to go. Having only one code to maintain is also better for you and for performance in the end.

In the current version having filter sync is great because find is sync too. But if in v2 everything is async it will be awesome. I've read what you're planning for v2, and it's really great.