-
Notifications
You must be signed in to change notification settings - Fork 9
Add transaction support to storage interface #1271
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Introduces IStorageTransaction with fork/commit/abort operations, consistency guarantees, and comprehensive error handling for transactional storage operations.
| }>; | ||
|
|
||
| export interface IStorageAddress { | ||
| the: The; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(not blocking merging this PR)
I wonder whether we should align this with the sigil terms, starting to push these more common names further down the stack.
So type, source, path.
source is a bit odd for writes.
So second - more urgent - question: Should we go back to id in sigils? Make it (eventually) consistent throughout the codebase?
cc @ubik2 as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest we leave this as is for now and when we update memory implementation we can update names here also.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not have to change sigils again, since then we'll have data with the wrong names, hence that one being more urgent. Will break it out.
Here we only define an interface to be implemented in a followup change. Goal is to discuss and build a consensus around what the API should be like to support desired use cases.
Summary by cubic
Added a new transactional storage interface with support for starting, committing, and aborting transactions, along with detailed error handling and consistency guarantees. This defines the API only and does not include an implementation.