-
Notifications
You must be signed in to change notification settings - Fork 11.3k
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
Event Store Initial Implementation #2507
Conversation
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.
Awesome work!
// to execute all inserts in a single statement? | ||
// TODO: See https://kerkour.com/high-performance-rust-with-sqlite | ||
for event in events { | ||
// If batching, turn off persistent to avoid caching as we may fill up the prepared statement cache |
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.
curious when does the cache get flushed?
/// Will return at most limit of the most recent events within the window, sorted in ascending time. | ||
fn events_by_module_id( | ||
/// Will return at most limit of the most recent events within the window, sorted in descending time. | ||
async fn events_by_module_id( |
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.
function_name
?
@longbowlu pushed a new commit to address most of your comments. Move event test also coming. |
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.
looks great
Initial implementation of the
EventStore
trait (and some modifications to it) based on SQLite and thesqlx
crate.Methods are enough for basic event store queries by event type and module/package ID, per events implementation plan.
NOTE: The choice to have a JSON field is to allow for easy filtering of any field within Move events and other events. However, it would take up more space and duplicate the binary data in a BCS field.
Also it gives flexibility to add more fields to other events in the future without having to dedicate a column to each.
The idea is that the separate columns are the main ones used for filtering things down.
To be added: