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
{{ message }}
This repository has been archived by the owner on Feb 7, 2019. It is now read-only.
Apologies for opening an issue when what I really have is a question.
I want to implement immutable / append-only models in our system (no UPDATEs only INSERTs), so we can store full history for our data. In other platforms I've done this with an integer versionId with a unique constraint on (versionId, id) columns. All saving code would try to insert rows with (versionId + 1, id). This also gave me concurrency control - if 2 clients both try to insert a row with the same (versionId, id) pair then it would fail and I could show a nice error page and not have the 'lost update' problem when 2 clients both try to update the same record.
cleanerversion looks very close to being what I need :) except that it uses timestamps instead of integers for versioning. I'm thinking of forking the project and changing the timestamps to integers but I wanted to ask - do you see any problems with this idea, and is there maybe a better way?
Thank you.
The text was updated successfully, but these errors were encountered:
I'm not sure about the specifics of your application, but it seems like you would also get an error with cleanerversion if you try to clone a particular object (e.g. an object with the same id and identity) twice. It should not be possible to clone a non-current (e.g. with version_end_date != null) version, so an error would be raised when a second process tries to clone the already-cloned-by-another-process object.
After looking at the code again, I see that what I said before is not true. Both processes would succeed in "updating" the object.
It seems like it wouldn't be too hard to adapt that so that the save only succeeds if the version_start_date of the in-memory object is the same as the version_start_date of the object in the database.
I've had a go at adding a version number field here: https://github.com/dhobbs/cleanerversion
It's broken at present but it looks achievable. Using monotonic integer version ids could also potentially improve query performance (although that's not my main motivation)
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi,
Apologies for opening an issue when what I really have is a question.
I want to implement immutable / append-only models in our system (no UPDATEs only INSERTs), so we can store full history for our data. In other platforms I've done this with an integer versionId with a unique constraint on (versionId, id) columns. All saving code would try to insert rows with (versionId + 1, id). This also gave me concurrency control - if 2 clients both try to insert a row with the same (versionId, id) pair then it would fail and I could show a nice error page and not have the 'lost update' problem when 2 clients both try to update the same record.
cleanerversion looks very close to being what I need :) except that it uses timestamps instead of integers for versioning. I'm thinking of forking the project and changing the timestamps to integers but I wanted to ask - do you see any problems with this idea, and is there maybe a better way?
Thank you.
The text was updated successfully, but these errors were encountered: