Community
Participate
Working Groups
Currently, there is only a HorizontalAuditMappingStrategyWithRanges. Branching is not supported. Therefore, a HorizontalBranchingMappingStrategyWithRanges should be implemented which supports the range-based list table mapping optimization with branches as well.
Created attachment 182099 [details] patch-v1 This patch contains the implementation of the new HorizontalBranchingMappingStrategyWithRanges. To enable it, use "horizontalBranchingWithRanges" in your server configuration file. The mapping strategy supports two modes: copy-value-on-demand (default) and copy-on-branch. The modes affect the storage and retrieval of values of unbounded features (isMany == true). In the copy-on-branch mode, if a branch is created, any revision that is modified in the branch leads to a complete copy of all values of all features. E.g., suppose you have an object o with a feature foobar which contains a list of int values (1,2,3,4,5). Then you create a branch and delete the last int. Then you end up in the branch with o.foobar having (1,2,3,4) stored directly in the branch. (If you had modified another feature of o, then the complete list (1,2,3,4,5) would have been stored for the branch). This way, all values are present in all branches all the time and read-access should be rather fast at the cost of using up more storage in the DB and an additional one-time effort when a revision is first modified in a brach. In the default copy-value-on-demand mode, no copy is made as long as it isn't needed. Instead, the values of unbounded features are determined by a cascade of the data known to the current branch and the respective data in the parent branches (aka base-revisions). In the example above, only a marker representing the deletion of the last integer would be stored for the branch in the database (or no data at all if the list remains unchanged). On a read access, the values of the list would be determined by reading the list size (which is now always stored as part of the attributes table) and by filling the list from the data in the current branch. Data that cannot be resolved in the current branch is resolved recursively from the base revisions (or: parent branches). The desired mode can be toggled by setting the property "copyOnBranch" for the mapping strategy. (if missing, a value of "false" is assumed, making the copy-value-on-demand mode default). The patch given here passes the complete CDO test suite. (there are 3 errors in the WorkspaceTest class, but these have nothing to do with this patch..) Comments welcome.
Created attachment 182571 [details] Patch-v2 Implementation remains the same. I have added two test classes to test the different list operations in branching scenarios, as this affects the main mechanism of the rang-based implementation. The test classes don't lead to an error; this is a good sign that the implementation is stable enough to be committed. So please review.
Created attachment 182572 [details] Patch-v3 v2 was incomplete
Created attachment 182639 [details] Patch v4 - ready to be committed I just removed various build.xmls from features that were probably left-overs from local exports. I don't like the Assert.assertTrue(false) thing so much, but hey...
Just to be clear, the previous startegy was named horizontalAuditWithRanges and the new one horizontalBranchingWithRanges but it still does support audit, right? That has not been dropped along the way? Or does branching always include audit?
> but it still does support audit, right? Yes. > That has not been dropped along the > way? Or does branching always include audit? Yes ;-)
On the one hand, branching always includes audit support (branching just adds a branch ID column to each table). So you can use the new strategy as a replacement for the old one. On the other hand, if you don't want the additional column, you can still stick to the audit-only strategy. I haven't replaced it, I just copied from the old strategy to create the new one.
Committed to HEAD.
You've broken the tests in non-branching modes! I've fixed that together with Martin...
Moving all open enhancement requests to 4.1
Reverting the previous status change which was accidental.
According to the date of comment #8 the version should be 4.0.
