Skip to content
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

feat(*): major updates to the keyvalue interfaces #30

Merged
merged 14 commits into from
Jan 19, 2024
Merged

feat(*): major updates to the keyvalue interfaces #30

merged 14 commits into from
Jan 19, 2024

Conversation

Mossaka
Copy link
Collaborator

@Mossaka Mossaka commented Nov 30, 2023

This commit has changed many function signatures to account for the scenario where the key does not exist. Instead of returning an error for non-existance keys, the expected behvaior should be returning a none for the client to handle.

The other changes are for providing more clarity to the behavior of the APIs ine wasi:keyvalue interfaces. It explained what it means to have batch operations without guarantees to atomicity and what are atomic operations like CAS.

It also changed the portability criteria to follow the newest WASI proposal template, and added a new goal regarding keyvalue operation performance in this proposal.

It also changed the readwrite and batch interface names to eventual and eventual-batch to indicate the operations are expected to run in an eventual consistent platform.

Closes #24 #25 #9

Copy link
Collaborator

@devigned devigned left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly editorial nits. Great work!

keyvalue-handle-watch.md Outdated Show resolved Hide resolved
keyvalue.md Outdated Show resolved Hide resolved
keyvalue.md Outdated Show resolved Hide resolved
wit/atomic.wit Outdated Show resolved Hide resolved
wit/batch.wit Outdated Show resolved Hide resolved
wit/readwrite.wit Outdated Show resolved Hide resolved
wit/readwrite.wit Outdated Show resolved Hide resolved
wit/readwrite.wit Outdated Show resolved Hide resolved
wit/readwrite.wit Outdated Show resolved Hide resolved
README.md Outdated
Implementations available for at least Windows, Linux & MacOS.
`wasi:keyvalue` must have at least two complete independent implementations demonstrating
embeddability in a production key-value store context. The implementations must be able to run
on at least two different operating systems.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Usually we enumerate linux, macOS, Windows. I'd prefer we don't deviate from that unless necessary

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My impression is that, unlike wasi:filesystem and wasi:sockets, the underlying OS doesn't really matter for wasi:keyvalue. Instead, what I think matters quite a lot is that wasi:keyvalue can be implemented in terms of relevant mainstream key-value servers/databases, including both open-source implementations (say Redis or RocksDB or etcd or ?) and proprietary public cloud implementations (say CosmosDB or DynamoDB). Saying just "two" seems to perhaps set the bar too low, although I'm not sure exactly what the right bar is.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree that wasi-keyvalue should be able to implement mainstream keyvalue stores. Will add that to the portability criteria.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've modified the portability criteria to include all three OSes and at least two impl in both open-source and proprietary keyvalue stores. (That means at least 4 impls)

wit/batch.wit Outdated Show resolved Hide resolved
Copy link
Collaborator

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really like this, just some super minor nits I found while reading through

wit/atomic.wit Outdated Show resolved Hide resolved
wit/batch.wit Outdated Show resolved Hide resolved
wit/error.wit Outdated Show resolved Hide resolved
///
/// A read/write operation is an operation that acts on a single key-value pair.
///
/// The value in the key-value pair is defined as a `u8` byte array and the intention
Copy link
Collaborator Author

@Mossaka Mossaka Dec 19, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This comment is added after all the code reviews to clarify why the value in key-value pair is defined as a list<u8>.

Copy link
Collaborator

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These changes all look great to me

Copy link
Collaborator

@devigned devigned left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

@Mossaka
Copy link
Collaborator Author

Mossaka commented Jan 4, 2024

Could you PTAL? @lukewagner

@Mossaka Mossaka mentioned this pull request Jan 4, 2024
Copy link
Member

@lukewagner lukewagner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great work here! While we probably need more work precisely specifying consistency, this seems like a good starting point for a proposal at this stage. But since names are always harder to change later, I'd like to suggest a few superficial renamings to anticipate future additions; lemme know what you think:

wit/world.wit Outdated Show resolved Hide resolved
wit/readwrite.wit Outdated Show resolved Hide resolved
Mossaka and others added 9 commits January 5, 2024 12:57
… get-keys

This commit has changed many function signatures to account for the scenario
where the key does not exist. Instead of returning an error for non-existance keys,
the expected behvaior should be returning a none for the client to handle.

The other changes are for providing more clarity to the behavior of the APIs
ine `wasi:keyvalue` interfaces. It explained what it means to have batch operations
without guarantees to atomicity and what are atomic operations like CAS.

It also changed the portability criteria to follow the newest WASI proposal template,
and added a new goal regarding keyvalue operation performance in this proposal.

Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Co-authored-by: David Justice <devigned@users.noreply.github.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
@Mossaka Mossaka changed the title feat(*): updated comments and changed signatures of get, get-many and get-keys feat(*): major updates to the keyvalue interfaces Jan 16, 2024
Signed-off-by: Jiaxiao Zhou (Mossaka) <duibao55328@gmail.com>
Copy link
Collaborator

@thomastaylor312 thomastaylor312 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm good with this and think we just need to merge and move forward. One point of dissent I want to record for posterity sake is that I think this interface is the wrong place to be worrying about having different types of consistency guarantees. These are supposed to be for the so-called "80% use case" and I think that just having a basic get/set/del/list along with their batch equivalent should be useful. Elsewhere I've proposed a wasi-cloud-ext world that could contain stricter things around consistency guarantees for a keyvalue interface

@Mossaka
Copy link
Collaborator Author

Mossaka commented Jan 18, 2024

Could you please take another look, @lukewagner?

Copy link
Member

@lukewagner lukewagner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for all the consideration! lgtm

@Mossaka Mossaka merged commit 9cde2eb into main Jan 19, 2024
1 check passed
@Mossaka Mossaka deleted the updates branch January 19, 2024 22:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants