Conversation
danderson
left a comment
danderson
left a comment
There was a problem hiding this comment.
Calling time on this first round of review. I didn't get all the way into the implementation of transactions and indexes, but I got through the schema and storage machinery.
My main thought is "wow that's a lot of type and lifetime parameters" 😂 I can see how they become necessary to make everything strongly typed, it just makes the logic hard for my tiny mind to follow. That said I think the worst of it ends up hidden way by the schema macros, so hopefully actually using a concrete store should be relatively pleasant.
I'll come back later for a second run at the remaining pieces.
| //! into transactions which are atomic and serializable. Both singleton and tabular data can be part | ||
| //! of a transaction, and tables and transactions are orthogonal. Transactions may be read/write or | ||
| //! read-only. Transactions don't need to be explicitly committed - the effect is 'commit on drop' | ||
| //! but the implementation is that operations are individually committed. |
There was a problem hiding this comment.
I don't understand the implementation part of this statement. My reading of it is that it says that if dropped, the transaction applies its changes but does so in a non-transactional way, where readers can observe partial applications. Hopefully I'm wrong?
There was a problem hiding this comment.
Ditto — what happens on a panic unwind or error rethrow via ? — I assume we normally don't want that state to be committed
| //! into transactions which are atomic and serializable. Both singleton and tabular data can be part | ||
| //! of a transaction, and tables and transactions are orthogonal. Transactions may be read/write or | ||
| //! read-only. Transactions don't need to be explicitly committed - the effect is 'commit on drop' | ||
| //! but the implementation is that operations are individually committed. |
There was a problem hiding this comment.
Ditto — what happens on a panic unwind or error rethrow via ? — I assume we normally don't want that state to be committed
Signed-off-by: Nick Cameron <nrc@ncameron.org>
Signed-off-by: Nick Cameron <nrc@ncameron.org>
3 participants
Adds a new crate, ts_kv_store, with the first increment of a typed, in-memory KV store. So far what is implemented:
I think this corresponds to the first two increments + indexes from the planning doc. Other than stuff discussed in meetings/on Slack, I don't think the implementation differs from the requirements or plan.
AI declaration: most tests are generated by Claude and reviewed by me. Everything else is written by human. I've had Claude review some of the code to help find bugs then addressed the bugs manually. I don't believe I actioned anything that wouldn't have been recommended by a human reviewer (but the code should absolutely still be reviewed by at least one human, sorry to that human in advance).
There are quire a few TODOs scattered around, I don't think any of them need fixing before landing. Some are things I intend to fix very soon, and some are longer term which I should turn into issues.
Closes #206, cc #169