Share sub-paths in reverse write-backs during mutation operations #47

Open
opened 2026-07-27 08:06:30 +00:00 by UserCurt · 0 comments
Owner

set and remove currently consider each attempted mutation as separate, even when multiple mutations share common chunk ancestors.

For example:

mpath.set(data, "/Settings<1>/{Width,Height}", {width, height}, UniformValues=false);

This current expands as:

settings = data.Settings;
settings.Width = width;
data.Settings = settings;

settings = data.Settings;
settings.Height = height;
data.Settings = settings;

This issue proposes expanding as:

settings = data.Settings;
settings.Width = width;
settings.Height = height;
data.Settings = settings;

This can increase the number of assignments that gets performed unnecessarily, especially for deeply branched paths such as in /*/*/*/*/*/*.

The proposed approach would build a shared reverse write-back tree from the mutation plan. Each tree node would represent one indexing chunk, and edges would represent retrieval and reverse write-back between chunks. Mutation paths with a common chunk prefix would share a parent node.

Each node would perform each child mutation before the parent can be mutated. So mutations would apply in a leaf-to-root ordering.

This issue depends on the forward and reverse chunk-planning model selected in #48. The two issues should be designed together and may be implemented in the same series of commits.

  • If the plan shares forward and reverse boundaries (options 1 or 3), the write-back tree should reuse route and chunk metadata from the traversal engine.
  • If the plan allows different forward and reverse boundaries (options 2 or 4), the write-back tree could not reuse all metadata from the traversal engine.

Similar to the current implementation, each UniformPaths group will be applied largely separately but here as separate sub-trees in the plan.

Complete terminal CSL assignment rounds must remain grouped (see completed #42). Repeated assignments must not be dropped or merged. Broader duplicate and ancestor/descendant behavior and ordering remains tracked by #46.

`set` and `remove` currently consider each attempted mutation as separate, even when multiple mutations share common chunk ancestors. For example: ```matlab mpath.set(data, "/Settings<1>/{Width,Height}", {width, height}, UniformValues=false); ``` This current expands as: ```matlab settings = data.Settings; settings.Width = width; data.Settings = settings; settings = data.Settings; settings.Height = height; data.Settings = settings; ``` This issue proposes expanding as: ```matlab settings = data.Settings; settings.Width = width; settings.Height = height; data.Settings = settings; ``` This can increase the number of assignments that gets performed unnecessarily, especially for deeply branched paths such as in `/*/*/*/*/*/*`. The proposed approach would build a shared reverse write-back tree from the mutation plan. Each tree node would represent one indexing chunk, and edges would represent retrieval and reverse write-back between chunks. Mutation paths with a common chunk prefix would share a parent node. Each node would perform each child mutation before the parent can be mutated. So mutations would apply in a leaf-to-root ordering. This issue depends on the forward and reverse chunk-planning model selected in #48. The two issues should be designed together and may be implemented in the same series of commits. - If the plan shares forward and reverse boundaries (options 1 or 3), the write-back tree should reuse route and chunk metadata from the traversal engine. - If the plan allows different forward and reverse boundaries (options 2 or 4), the write-back tree could not reuse all metadata from the traversal engine. Similar to the current implementation, each `UniformPaths` group will be applied largely separately but here as separate sub-trees in the plan. Complete terminal CSL assignment rounds must remain grouped (see completed #42). Repeated assignments must not be dropped or merged. Broader duplicate and ancestor/descendant behavior and ordering remains tracked by #46.
UserCurt added this to the Release v1 milestone 2026-07-27 08:06:30 +00:00
UserCurt modified the milestone from Release v1 to Release v2 2026-07-28 23:51:38 +00:00
Sign in to join this conversation.
No description provided.