This repository has been archived by the owner on Sep 30, 2023. It is now read-only.
Interface-datastore compliance #40
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What this PR adds
Query()method as diagrammed ininterface-datastoreBatch()method as diagrammed ininterface-datastoreHas()method as diagrammed ininterface-datastoreinterface-datastoreKey Object. (Open to additional discussion).What this PR does not add
Reasoning
Adding the query method is absolutely necessary for applications developers wanting to query key-values with or without a particular prefix. There is currently no API in kvstore that does anything similar. Discovering keys or routinely processing the entire store is not possible with the current API. However, there is an in memory index that can be queried no different than a normal javascript object. This works! But there is no guarantee that the same logic can be provided with different indexes down the road. Using a disk backed index cannot provide the same level of access for example.
I believe adding batch method is necessary for future changes. For example supporting modifying multiple key-value records inside a single oplog entry. Currently batch method commits modifications in multiple oplog entries, this is left open to future implementation modifications supporting multi key-value modification inside a single oplog entry.
By having a solid, well established common interface providing the same API level functionality regardless of implementation, I believe is key to long term utilization
I am open to further discussion on implementation, or alternative approaches.