Bug 300020 - [DB] Develop a delta-mapping
Summary: [DB] Develop a delta-mapping
Status: NEW
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.db (show other bugs)
Version: 4.13   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2010-01-19 02:21 EST by Stefan Winkler CLA
Modified: 2020-12-11 10:44 EST (History)
1 user (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Winkler CLA 2010-01-19 02:21:13 EST 
This idea has been floating around in Eike's an my heads for a while.
A mapping should be developed which combines the performance of the non-audit store with an auditing capability. 

The result could be a delta-mapping for the DBStore which uses the existing non-audit mapping implementations and augments it with a mechanism to store reverse revision-deltas in separate tables. The behavior would be similar to RCS/CVS: the most current version (HEAD) would be stored as is (hence the reuse of non-audit mappings) and if a new revision is committed, the backwards delta is calculated and stored. 

This trades off auditing performance for speed when working with the current version: When accessing an old revision, it has to be reconstructed by fetching the HEAD revision and applying the backwards deltas until the desired version is reached.
Comment 1 Eike Stepper CLA 2010-01-19 02:27:10 EST 
Some thoughts:

1) Optionally there could be additional snapshot revisions every X revisions, like the correction frames in an mpeg. X could be configurable. By annotation?

2) Would a single blob column for the serialized CDORevisionDeltas be sufficient?
Comment 2 Eike Stepper CLA 2010-06-29 04:50:19 EDT 
Rebasing all outstanding enhancements requests to version 4.0
Comment 3 Eike Stepper CLA 2011-06-23 03:57:29 EDT 
Moving all open enhancement requests to 4.1
Comment 4 Eike Stepper CLA 2012-08-14 22:55:43 EDT 
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 5 Eike Stepper CLA 2013-06-27 04:06:15 EDT 
Moving all outstanding enhancements to 4.3
Comment 6 Eike Stepper CLA 2014-08-19 09:23:28 EDT 
Moving all open enhancement requests to 4.4
Comment 7 Eike Stepper CLA 2014-08-19 09:35:06 EDT 
Moving all open enhancement requests to 4.4
Comment 8 Eike Stepper CLA 2015-07-14 02:18:14 EDT 
Moving all open bugzillas to 4.5.
Comment 9 Eike Stepper CLA 2016-07-31 01:01:06 EDT 
Moving all unaddressed bugzillas to 4.6.
Comment 10 Eike Stepper CLA 2017-12-28 01:12:23 EST 
Moving all open bugs to 4.7
Comment 11 Eike Stepper CLA 2019-11-08 02:18:10 EST 
Moving all unresolved issues to version 4.8-
Comment 12 Eike Stepper CLA 2019-12-13 12:54:28 EST 
Moving all unresolved issues to version 4.9
Comment 13 Eike Stepper CLA 2020-12-11 10:44:15 EST 
Moving to 4.13.