Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

MVCC is not versioning. MVCC is concurrency control.

I would have to be convinced that the DB is an appropriate place to handle versioning of the kind you are speaking of.

For instance, see this article: http://www.xaprb.com/blog/2013/12/28/immutability-mvcc-and-g... Upshot is that RethinkDB started out append-only with rewindability etc. and then ran into real-world problems.

Every system I've ever seen that did versioning does it at the software level and stores multiple records in the database.

Rails gem "paper trail" is an example.



That's a fair point. I sat down and tried to sketch it on paper after posting my comment, and found there was too much domain knowledge involved to do versioning directly in the database.

My comment can be rephrased that it's still painful to do this at the application level: for such a common task, the frameworks/libraries/software I work with don't have anything baked in to handle it.

I've started trying to use Git as an additional data backend to hold the versioning, but changing from a JSON/Database storage structure to one Git will happily diff and reconcile is in itself not pretty.


SQLite might be a tolerable solution for that, as long as you can stop the world between commits.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: