pubkey / event-reduce Goto Github PK

Issue
Unable to install RXDB (which depends on event-reduce-js) following the installation instructions found at https://github.com/pubkey/rxdb due to low and high-severity vulnerabilities.

NPM Audit Report
Running npm audit in a Visual Studio Code 'terminal' reveals 11 vulnerabilites (8 low, 3 high severity) are found. Preventing installation.

Seems that ueberdb could leverage this really well. It'd be cool to bring it in. Https://GitHub.com/ether/ueberdb

I can understand the use-case for this library, but I don't understand (even marginally) the "how" of it.

Let's take the example query in the readme:

const exampleQuery: MongoQuery = {
    selector: {
        age: {
            $gt: 18
        },
        gender: 'm'
    },
    limit: 10,
    sort: ['name', '_id']
};

And let's say these are the initial database contents: (as JSON)

[
    {gender: "m", age: 10, name: "Bob"},
    {gender: "m", age: 20, name: "Dan"},
    {gender: "f", age: 10, name: "Alice"},
    {gender: "f", age: 20, name: "Sally"},
]

So then, the initial result set for the query would be this:

[
    {gender: "m", age: 20, name: "Dan"},
]

However, let's say a new user was just added:

{gender: "m", age: 30, name: "Mike"},

The new entry is, of course, a match for the query. And since the name "Mike" is later than "Dan", it should be added to the end of the query result set (rather than the start).

My specific question for this case then is: How on earth is your generic event-reduce algorithm able to know that the new "Michael" entry should be added after the "Dan" entry rather than before it?

This is of course easy to solve if you're hand-coding the query-result update system (eg. you do a binary search through the old results, to find the insert point for the new entry). But I currently have no idea how your library is able to accomplish this generically, based just on the MongoQuery params, the old results, and a change-stream entry. (it seems like it would have to recreate the entire MongoDB query execution code within the library -- yet the library's described as not being specific to MongoDB)

As explaining the entire algorithm would be too much to ask, I give the specific case above, in the hopes that there is an intuitive answer that can be given for this small case, that can give insight into how the library solves these cases in general.

This issue provides visibility into Renovate updates and their statuses. Learn more

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency minimongo to v6.9.0
• Update dependency typescript to v4.4.3
• Update dependency css-loader to v6
• Update dependency less-loader to v10
• Update dependency style-loader to v3
• Update dependency ts-loader to v9
• Update dependency webpack to v5
• Click on this checkbox to rebase all open PRs at once

• Check this box to trigger a request for Renovate to run again on this repository

We discovered some scary behavior in our app where items were being sorted wrong. We dug into and realized that event-reduce is actually suggesting an insertLast when it should be an insertFirst.

Here's the test case showing it: #443

I thiiink (though I don't fully understand the library yet) the issue is somewhere in the truth table to bdd conversion?

I think this because the json truth table calculateActionFromMap seems to correctly tell us runFullQueryAgain (well it's not ideal, which would be insertFirst, but it doesn't give us incorrect results) for this case of 0101000000010011001.

However, calculateActionName is wrong. It tells us to insertLast.

--

We can obviously patch this, but the issue opens up some serious questions for us:

1. From reading the iterative fuzzing process, it seems there is no guarantee of correctness -- is that true?
2. How can we be confident there are no further issues like this?

This is really cool. It reminds me of https://github.com/mit-pdos/noria a bit.