Fork me on GitHub

@dave.dixon the query params are defined at query creation time and then used to key the results for the query in a map. This results in the actual call to “query” basically just being a map lookup. If arbitrary keys could be missing, I don’t think you could look things up that way without creating a lookup table for every possible permutation of absent and present bindings during fire-rules time, which could become costly. Looking at the code it seems perhaps we could add logic allowing the user to either pass all present params or none, providing all results regardless of bindings in the later case. Relevant code sections: for the query implementation in the engine, note the mem/get-tokens call. In QueryNode note the memory calls as well: with the join-bindings coming from the param-keys via this: Then see get-tokens and get-tokens-all: ; get-tokens-all would ignore the bindings


@wparker Thanks, good insight on working memory. It looks like the inspect function illustrates how to get at the bindings via get-tokens-all.