Community
Participate
Working Groups
Build Identifier: 4.0 Objects created on a local offline branch have a big id. After a merge to an online branch these merged objects have a new id. Example: -> View V opened on local branch -1 -> Object A is created offline: A@99999999999 -> Merge branch -1 to main branch -> View V is switched to main branch 0 -> Object A becomes invalid because on the main branch a new id is assigned (e.g. A@22). The state of objects which are valid on both branches becomes PROXY and these object are reloaded on access. Offline created object are detached after the branch switch because these object to not exist on the main brach. It would be nice to apply an id mapping on the view on the main brach after a branch switch. By this it would be possible to keep references on offline created objects. Reproducible: Always
Created attachment 174123 [details] Patch to support id mappings on branch switches Tried not to change public api. - In CDOTransactionImpl.mapLocalIds the id mapping is stored in the merger because CDOTransaction already returns the change set. - When switching the branch on a view the mapping is given to the setBranchPoint method (which is defined in InternalCDOView. Flaws: - The merger cannot be used concurrently because the id mapping is overwritten. - Had to change internal API: InternalCDOView, InternalCDOTransaction - Merger API changed.
Will add a testcase which checks if references to offline created object are correctly mapped.
Created attachment 174126 [details] Testcase for id mapping This testcase checks if the offline created objects can be reused after a branch switch and if multiple offline created objects having references to each other can be normally accessed after the branch switch. -> Only use this patch after patch 174123 is applied.
I confirm to 1) The number of lines that you changed is smaller than 250. 2) You are the only author of these changed lines. 3) You apply the EPL to these changed lines. for each attachment.
Created attachment 175124 [details] Patch v1 - incomplete New approach: - Collect idMappings where they arise (tx: applyChangeSetData and commit) - Transport to server - Persist with commitInfo - Notify to other sessions, but DON'T cache them there! - When they are needed during particular branch switches of a CDOView, request them from the server (ChangeViewTargetRequest), use and release them.
Created attachment 175540 [details] Patch v2 - incomplete
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
