Initial implementation of whereEq queries

[JonoPrest]

Implements "where equals" query for loaders on all indexed fields.

Flow:

• loader calls the query
• during loader execution query creates an "index" in the entity tables (if it doesn't already exist)
• if query is unique it gets executed and values added to the in memory table.
• The index set on the in memory table means that every add will evaluate and index its ID if it matches
• At the end the loader will look up the index via in memory store to get matching ids
• set and delete functions on an entity will manage current indices on the table

Note this can only be done in a loader because... In the scenario where you add a new entity that exists only in memory. The index needs to exist on the in memory table before the add in order for it to appear on lookup in the index.

Deleting an entity will search through all indices on that entity and remove its id from any index it exists in.

The mock db in test helpers will currently prune all indexes of an entity and then add indexes for all fields of that entity every time an operation is called to prevent stale values existing in indices.

[JonoPrest]

Note to revert back to dict

[DZakh]

Reviewed everything besides codegenerator/cli/templates/static/codegen/src/InMemoryTable.res
I'll continue tomorrow morning. Looks good so far

[DZakh]

It might not work for array of BigDecimal

[DZakh]

If we handle them in a custom way, then we can use === instead of Caml_obj.equal, which should be a little bit faster and clener output

[DZakh]

If we handle them in a custom way, then we can use === instead of Caml_obj.equal, which should be a little bit faster and clener output

This comment is optional

[DZakh]

Let's remove curring from here

[DZakh]

A comment for future. If there's an external await in between of .load method calls, then hasLoadActions check won't be able to track it exit. It'll cause the .load method to stack as an unresolved pending promise.

[DZakh]

Just a random idea, but theoretically, it might be faster. But the number of allocated function contexts is a concern

Suggested change

	| Some({loadCallbacks}) => loadCallbacks->Js.Array2.push(loadCallback)->ignore
	| Some(lookup) => {
	lookup.callback = (v) => {
	lookup.callback(v)
	loadCallback(v)
	}
	}

[DZakh]

Another fun idea, which will probably be even more performant is to create a pending promise and expose the resolve function:

let resolveRef = ref(%raw(`null`))
let resultPromise = Promise.make((resolve, _reject) => {
  resolveRef := resolve
})

// Store both resultPromise and resolve in the LoadLayer

// Then when we add a new item to the LoadLayer we can do:
let _ = resultPromise->Promise.thenResolve(callback)

// And to actually resolve everything simply run the resolve function
resolve(result)

[DZakh]

note: I don't have benchmarks and since it's not a bottleneck, you don't need to change anything

[JonoPrest]

Let's chat through some of these thoughts on a call! Definitely keen to squeeze more performance.

[DZakh]

I didn't read some places in much details, but in general I don't have any comments 👍