- To: email@example.com
- Subject: Versioning
- From: "Alexey Parshin" <firstname.lastname@example.org>
- Date: Fri, 20 Oct 2006 17:27:26 +1000
- Delivered-to: mailing list email@example.com
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=jiWyQ3ERmXEQ3DFiRbMWJp+RrTU8eKVOvoDJP0YRiEhp4xmF1Lz9MNKQWz89dl4BoerRy0VCtKovFhvUi73xCqeU51/kFfu5wydPT1ZpyZDKS8TFgD0VNwZ3r5WF3DKsI6Rgpd7sGI9Rk0neR6A8O5t/B0wX1p7Up8V6GI1O32I=
- Mailing-list: contact firstname.lastname@example.org; run by ezmlm
There are several ways to do versioning.
Here is one:
Every object should have a version number, a reference to an object it's derived from (previous version), and a reference to the original object. The separate table should hold object class, original object id, and the latest version of that object available.
The question is how to indicate the latest version of the object. We can move the connections of the old version to the new version, if the new version stays with the same parent object. If we need to step back to prior version - we just switch connections to required version. All the versions have the same original object id reference.
2006/10/20, Ilya A. Volynets-Evenbakh <email@example.com>:
Few more things, at we are going to be in good enough shape to
start writing stored procs
- I don't see where student's solution of a problem is stored
- Versioning support
- DoT doesn't look too close to what I was thinking, but I'll leave
it alone till I know what it really should be working like.
Probably there are other things I missed, so we'll change
schema later as needed.
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
- Re: Versioning
- From: "Ilya A. Volynets-Evenbakh" <firstname.lastname@example.org>