Skip to content

Improve Version constructor logic #146

@joepio

Description

@joepio

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions