The in-memory half of io.eezo.core.Store: where a model's rows live when nothing persists them.
It is what a model deriving Form, Resource and no Table gets, so the seven routes mount and serve without a database anywhere in the build. The JDBC half lives in db, and the generated route table is where the compiler picks between them per model.
Named for its implementation rather than Store, so that core's trait is the only thing in the build called Store and a call site never needs a package to say which one it means. The type is public only because generated code has to name it. No user writes it by hand.
A store of its own, sharing nothing with any other. That is what makes a test that calls the generated Routes.table() start from an empty world with no reset step.
A store of its own, sharing nothing with any other. That is what makes a test that calls the generated Routes.table() start from an empty world with no reset step.
Unlike JdbcStore.owned, which narrows the very table JdbcStore[A]() already reads, this call has nowhere to take somebody else's rows from: its only argument is the OwnerOf, so the map underneath is fresh and reachable by nobody but the value this returns. A mount that wants a whole store and a narrowing over the same rows together wants scoped, not this alongside a separately built InMemoryStore[A](), which would read and write two unrelated maps.
What by does share, across every call made on the one value this returns, is that same map: an insert through one owner's narrowing is visible to a later call narrowed to that owner, and to no other.
No given, which is the other difference from the JDBC half: that one needs a Column[V] to bind the owner into a statement, and this one compares two values the model already holds. ownerOf.get is the comparison, so a model whose owner field is an Id[User] is scoped by Id's own equality and nothing here learns what a user is.
The pair an owned model's routes are mounted over: the whole table for the actions ownership does not cover, and the narrowing for the ones it does, over one set of rows.
The pair an owned model's routes are mounted over: the whole table for the actions ownership does not cover, and the narrowing for the ones it does, over one set of rows.
One call rather than two, because two would be two maps: a derived index reading a store no create ever wrote to is an empty page that no test of either half on its own would catch.
