You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Commits can be played back in order to construct a specific version of a Resource. The current versioning implementation #42 does this fine, but the current approach has some major flaws.
First, I tried to instantiate a new empty Store, and apply all commits over there. The downside of this, is that it is very slow, because every .set action with a property unfamiliar to that store, will result in a fetch - the store needs to know that property in order to actually set the data.
Then, I tried to temporarily remove the resource from the store, construct it from commits, return the constructed resource, and put back a clone of the original resource. This is way quicker, but it is kind of dirty. Firstly, if anything goes wrong in between - the data is gone or damaged. Secondly, if someone fetches the edited resource while the commits are being applied, we could very well get a wrong representation of that resource, and this turns out to happen every time we try to render the /all-versions endpoint for some resource. Not good.
So I tried to have an optional parameter to the commit function for a guest_store, which could be used as a source for the properties, but Rust doesn't like using two different impl trait inputs in one function.
Maybe there is another aproach. Perhaps the commit function should return also returns the resource that is to be added to the store, instead of directly adding it to the store by itself. We could have a more detailed commit_extra function... Or maybe extract the set and remove logic to a separate method in Commit. Yeah, let's do that.
The text was updated successfully, but these errors were encountered:
Commits can be played back in order to construct a specific version of a Resource. The current versioning implementation #42 does this fine, but the current approach has some major flaws.
First, I tried to instantiate a new empty Store, and apply all commits over there. The downside of this, is that it is very slow, because every
.set
action with a property unfamiliar to that store, will result in a fetch - the store needs to know that property in order to actually set the data.Then, I tried to temporarily remove the resource from the store, construct it from commits, return the constructed resource, and put back a clone of the original resource. This is way quicker, but it is kind of dirty. Firstly, if anything goes wrong in between - the data is gone or damaged. Secondly, if someone fetches the edited resource while the commits are being applied, we could very well get a wrong representation of that resource, and this turns out to happen every time we try to render the
/all-versions
endpoint for some resource. Not good.So I tried to have an optional parameter to the
commit
function for aguest_store
, which could be used as a source for the properties, but Rust doesn't like using two differentimpl
trait inputs in one function.Maybe there is another aproach. Perhaps the
commit
function should return also returns the resource that is to be added to the store, instead of directly adding it to the store by itself. We could have a more detailedcommit_extra
function... Or maybe extract theset
andremove
logic to a separate method in Commit. Yeah, let's do that.The text was updated successfully, but these errors were encountered: