This unsolvable maze is a local food from Bangladesh, known as Jilapi Photo credits to udvranto pothik |
There's gotta be an easier solution!But, I am yet to find one. So, I am thinking it's one of those open design problems, may be.
To clarify the requirement with an example, let's consider the following scenario:
A lawyer is preparing a document for one of her clients using a software. On January 17th, she needs to take a look at the version of the same document from May last year so that she can backtrace some changes that took place during these months.
Lets assume the lawyer is using a software that stores the documents in a relational database with the following schema.
A Document has many Evidences, each provided by an EvidenceProvider Document (id, client_id, case_id, name) Evidence (id, document_id, evidence_provider_id, details) EvidenceProvider(id, name)Now, given the versioning requirement how would you design your data model?
Here's a couple of points that your design should address at a minimum:
- Going back to a version means a complete snapshot of the old version of the document. So, the version of May 1st should only bring the evidences that were there on that very day.
- As a new version is created, it should inherit all previous evidences.
However, in my latest project, the requirement is even harder. It's somewhat like this:
The lawyer may have some documents in the "work in progress version". This means, if she needs to print a document for the court, she only wants to print the last "good version", skipping the "work in progress version".
Also, when there is such a "work in progress version", she needs to attach any new Evidence to both the last "good version" as well as to the "work in progress version".
Well, now you see the design of a data model for Object Versioning becomes really messy and unintuitive.
So, here's my question to you - how would you design a solution for this?