-
Notifications
You must be signed in to change notification settings - Fork 68
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
Transactional/commit-based state #33
Labels
enhancement
New feature or request
Comments
elijahbenizzy
added a commit
that referenced
this issue
Feb 25, 2024
We weren't respecting it before. This handles that. This just measures the delete operations and reapplies it. That said, this is not the best way of doing things -- see #33 for a more involved approach.
elijahbenizzy
added a commit
that referenced
this issue
Feb 25, 2024
We weren't respecting it before. This handles that. This just measures the delete operations and reapplies it. That said, this is not the best way of doing things -- see #33 for a more involved approach. Note we've also relaxed the restrictions on modifications for delete/write -- this is necessary for the current workaround.
elijahbenizzy
added a commit
that referenced
this issue
Feb 25, 2024
We weren't respecting it before. This handles that. This just measures the delete operations and reapplies it. That said, this is not the best way of doing things -- see #33 for a more involved approach. Note we've also relaxed the restrictions on modifications for delete/write -- this is necessary for the current workaround.
elijahbenizzy
added a commit
that referenced
this issue
Feb 26, 2024
We weren't respecting it before. This handles that. This just measures the delete operations and reapplies it. That said, this is not the best way of doing things -- see #33 for a more involved approach. Note we've also relaxed the restrictions on modifications for delete/write -- this is necessary for the current workaround.
elijahbenizzy
added a commit
that referenced
this issue
Feb 26, 2024
We weren't respecting it before. This handles that. This just measures the delete operations and reapplies it. That said, this is not the best way of doing things -- see #33 for a more involved approach. Note we've also relaxed the restrictions on modifications for delete/write -- this is necessary for the current workaround.
elijahbenizzy
changed the title
Transactional/efficient state
Transactional/commit-based state
Feb 27, 2024
Reading for a conceptual model https://martinfowler.com/eaaDev/EventSourcing.html |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The plan here is from the docs. Problem is that we're eagerly evaluating state at every point which is not particularly efficient (TBD, however). This also helps us solve this in a clean way: #28.
We plan the ability to manage state in a few ways:
commit
-- an internal tool to commit/compile a series of changes so that we have the latest state evaluatedpersist
-- a user-facing API to persist state to a database. This will be pluggable by the user, and we will have a few built-in options (e.g. a simple in-memory store, a file store, a database store, etc...)hydrate
-- a static method to hydrate state from a database. This will be pluggable by the user, and we will have a few built-in options that mirror those inpersist
options.Currently state is immutable, but it utilizes an inefficient copy mechanism. This is out of expedience -- we don't anticipate this will
be painful for the time being, but plan to build a more efficient functional paradigm. We will likely have:
checkpoint
(allowing for state garbage collection), and store state in memory/kill out the pointers.We will also consider having the ability to have a state solely backed by redis (and not memory), but we are still thinking through the API.
The text was updated successfully, but these errors were encountered: